Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 35

Thread: Canonical To Develop Some Ubuntu Features In Private

  1. #21
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by Awesomeness View Post
    I'm sorry but you're wrong. Actually most successful FOSS projects are developed in an openly accessible repo, even though they are not advertised, yet. Even in case of Ubuntu you can usually browse on launchpad.net and find such projects or at least you could.
    http://en.wikipedia.org/wiki/Branching_%28software%29
    Yes, you can browse the project. Doesn't mean you can browse all branches.

  2. #22
    Join Date
    Dec 2010
    Posts
    1,147

    Default

    Quote Originally Posted by bug77 View Post
    http://en.wikipedia.org/wiki/Branching_%28software%29
    Yes, you can browse the project. Doesn't mean you can browse all branches.
    In most successful FOSS projects you can browse all branches. GNOME Shell was developed that way. From early mockups until final release: Everything was accessible from the outside.
    KDE even has a policy against private branches.

  3. #23
    Join Date
    Sep 2011
    Location
    Rio de Janeiro
    Posts
    202

    Default

    Quote Originally Posted by Figueiredo View Post
    Well, i hope this is one of those things not being openly developed according to the OP.
    "The source code of the execution environment isn't available yet, but the developers plan to publish it soon. They hope that making it available and inviting the community to participate will help build momentum around the project and accelerate development."

    Canonical might be learning something from valve...

    If canonical play it's card right, we could have homebuild "consoles" playing Steam, as well as OUYA games, that would put any other gaming platform to shame.

  4. #24
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,102

    Default

    Quote Originally Posted by Awesomeness View Post
    KDE even has a policy against private branches.
    Where? I don't see such on the SVN commit policy page:
    http://techbase.kde.org/Policies

  5. #25
    Join Date
    Jul 2012
    Location
    SuperUserLand
    Posts
    538

    Default

    "some sexy 13.04 surprises"



  6. #26
    Join Date
    Jan 2009
    Posts
    1,401

    Default

    Quote Originally Posted by Pallidus View Post
    "some sexy 13.04 surprises"


    That's extremely offensive.

  7. #27
    Join Date
    Dec 2010
    Posts
    1,147

    Default

    Quote Originally Posted by curaga View Post
    Where? I don't see such on the SVN commit policy page:
    http://techbase.kde.org/Policies
    I have no idea where. I've only read about it in a mailing list message quite a while ago. The dev of some KDE app had a private branch on his home PC and his merges to master/trunk overwrote changes that other devs did. That in turn broke translations which is why it came to light.
    The dev got an explanation that his development stye was against KDE policy.

  8. #28
    Join Date
    Jul 2012
    Location
    SuperUserLand
    Posts
    538

    Default

    offensive is having your operating system dial to X or Y when you perform a search (on your freaking drive)

    offensive is seeing a company so desperate to monetize they will allow their system to be 1. compromised 2. amazon's bitch.


    fuck canonical and fuck amazon, vive linux libre free of money grabbing parasites.

  9. #29
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by Awesomeness View Post
    I have no idea where. I've only read about it in a mailing list message quite a while ago. The dev of some KDE app had a private branch on his home PC and his merges to master/trunk overwrote changes that other devs did. That in turn broke translations which is why it came to light.
    The dev got an explanation that his development stye was against KDE policy.
    First, if it's not on their web site, it's not a policy. It's a recommendation, at best.
    Second, it doesn't sound like they have anything agaist private branches, but something against not rebasing before committing. And that's VCS 101.
    Third, easy branching for personal use us one of the chief reasons Linus bothered to write git.

  10. #30
    Join Date
    May 2011
    Posts
    12

    Default

    Running Android apps@PC

    There are other aspects as well - many Android applications are designed in the smartphone form factor in mind. While many work quite OK on tablets, stretching this to a desktop (1024x768 -> 1920x1080) might be a bit too much. Basically, you would get either really big icons (if they were specified as % of screen height/width) or really small ones (if their size was hardcoded in pixel). Also any non-vector graphics that gets resized would look like crap - either blurred or blocky, depending on the scaling algorithm.

    There can be also issues with text input - but as some Android devices have a hardware keyboard, it might be not that hard to connect the normal input methods to the Android environment. Not sure about more advanced issues though (runtime layout switching, unicode handling etc.).

    Regarding touch input - unless your monitor is a touchscreen (or maybe you have multitouch touchpad) you can't use any multitouch gestures, which some applications might be dependent on. But as there are also single-touch Android devices on the market, this might not be that much of a problem as the mainstream developers probably provide fall-backs for them.

    And the other way around - forget about using middle/right click & the scroll wheel. No Android applications have any notions of it. Also no on-hover help bubbles due to how touch input works. Some of it would be probably possible to fake back in (simulating up/down swipe on list widgets, long press on right click, etc.) but it would be far from consistent.

    Also, your PC mostly doesn't have all the sensors (accelerometer, magnetometer, gyroscope, light sensor, GPS, IRDA, NFC, camera) that actually make many applications useful.

    While I'm not saying it is completely pointless to do so (why not do it if it's possible ), I think the general usability of the Android applications running on PC might not be that high.

    Things might change if the developers took PCs in accounts as their targets or if more standard desktop Linux libraries and toolkits can be used for writing Android applications (the Necessitas project[1] is already working on this, it is also possible to use Python to write Android GUI applications[2][3] Its just still a little unpolished though. )

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •