Ubuntu's File Manager App Has A Long TODO List

[TheBlackCat]

The problem was that the our developers knew QML, but not much C++, and the Qt4/Qt5 UI were build in C++, so they couldn't do the work on the other UIs that was needed to make them work. And, appropriately, upstream wasn't going to land patches for the Ubuntu UI if they broke the Qt UIs. So we were at an impasse. The developers of the Ubuntu front-end started accumulating patches that worked for the Ubuntu UI but couldn't land in upstream without work done on the other UIs. Eventually they started releasing their patched version under the name Dekko, to make it available to users. Finally, after quite bit of discussion with the upstream project, they decided that the impasse wasn't going to be resolved any time soon, so the split was made official. Importantly, though, at no point were any of these decisions made by Canonical.

I am confused by this. The GUI of trojito is written in C++, but so is all of the backend code. If nobody working on the fork understands C++, how are they planning to maintain all the C++ backend code?

[TheBlackCat]

I doubt that the Nemo Mobile file manager (or Dolphin) does the extraction itself, but rather shells out to tar or zip for that, in which case it's mostly front-end work which we would have to do regardless. Probably the same for browsing network shares.

No, as with all KDE file managers, file dialog boxes, and file transfer tools, Dolphin shells out those things to the KIO library. KIO figures out what sort of thing it was told to get, converts that to a list of files, then sends that list back to a program to display (or not) in whatever manner it wants (this is a bit simplified, obviously, but that is the basic idea). So a program using KIO pretty much doesn't need to know or care what sort of thing it is browsing, it just has to display the list of files provided by KIO. Local directories, USB drives, archive files, discs, network shares, and websites are all pretty much exactly the same, there is pretty much no additional "front-end work".

[mhall119]

Ok, you might be right on that part.

Looks like my compiz knowledge is a bit rusty. Perhaps it was a project doomed to slowly die as madjr just said it basically had only one developer left. The subsequent hiring of that dev by canonical certainly sealed the compiz fate.

The important thing is that it's Canonical's fault, everything else is irrelevant.

[markg85]

I don't think so. The only still active compiz dev got employed by canonical, (and he was already doing his big rewrite of compiz with 0.9x). I think Kde and Gnome "screwed" compiz as a mayor player (outside of being WM for unity) when they started their own composting window managers.

Ok, you might be right on that part.

Looks like my compiz knowledge is a bit rusty. Perhaps it was a project doomed to slowly die as madjr just said it basically had only one developer left. The subsequent hiring of that dev by canonical certainly sealed the compiz fate.

[Akka]

True, but they merged back (compiz-fusion if i recall correctly). Then they got screwed by canonical.

I don't think so. The only still active compiz dev got employed by canonical, (and he was already doing his big rewrite of compiz with 0.9x). I think Kde and Gnome "screwed" compiz as a mayor player (outside of being WM for unity) when they started their own composting window managers.

[madjr]

True, but they merged back (compiz-fusion if i recall correctly). Then they got screwed by canonical.

wow the things I read...


this is what happened:

"Compiz-Fusion was the name given to a project that served as a number of plugins and utilities as a compliment to the freedesktop.org Compiz core. It represented the community aspect to Compiz development. After Novell departed the freedesktop.org Compiz project, it was decided by a five-member guiding council to discontinue the project as a separate project and instead merge it into one project called Compiz in February 2009."

http://wiki.compiz.org/ProjectHistory

and here's the rest of the story:

http://en.wikipedia.org/wiki/Compiz

Canonical actually did compiz a favor and kept it alive longer, No major desktop was going to use it anymore, specially Gnome, Kde, etc. gave it's back to it and CREATED THEIR OWN FROM SCRATCH.

so yea no one else wastes time recreating the wheel, just canonical.. right

[markg85]

google reinvents the wheel (android stack), mozilla (firefox os stack) also does its. From a commercial point of view, whats wrong with that?

Really.. You're going in that direction. Fine, I'll answer it.

When google forks something (or creates something from scratch when there is something else existing) and open sources it, it tends to be quite good and very open source friendly. It tends to be actually useful! Just look at blink and webkit, look at the entire linux kernel stack when it comes to embedded support. It all improved massively thanks to google. They use opensource and really improve it. While i don't particularly like Goolge, i do like how they thread the FOSS community. Much better then canonical.

When canonical forks something it's ending up "for their environment only" due to dependencies on their other crap therefore close to impossible to run on other linux distributions other then ubuntu and derivatives of it. In other words: it tends to end up as a ubuntu only software package that is useless for the rest of the foss world. If ubuntu where the only linux desktop it would probably be fine, but they aren't so it's not fine.. Canonical should get their act together and start acting like a part of the linux community. The only thing they give back is sick stuff like mir. Yet another example where they should have joined forces with wayland.

[markg85]

Beryl was never forked by canonical. Beryl was a fork of compiz. Nowadays canonical is compiz upstream (I think)

True, but they merged back (compiz-fusion if i recall correctly). Then they got screwed by canonical.

[Akka]

Fair enough.
But apparently the nemo components are quite limited if the todo list consists of such basic things like extracting compressed files and browsing network shares. I'm not saying the KDE classes are ideal, in KDE talk KIO is a tier 3 framework which means that it has a LOT of dependencies. It alone is probably unusable for anyone else except KDE due to dependencies it requires. But even that can be improved greatly. People just need to invest time into doing that.

That "time" point is exactly where i'm being annoyed by canonical. They seem to be creating some great stuff but all with reinventing existing technology. It would be much better to improve existing technology.

On the other hand, canonical has a very nasty habit to first try and join an existing project, then fork it. Beryl anyone? Trojita anyone?...

Beryl was never forked by canonical. Beryl was a fork of compiz. Nowadays canonical is compiz upstream (I think)

[lolnope]

I believe they are going through this whole effort of making everything of their own (including the infamous Mir display server) just to have full copyright of the entire software stack of the Ubuntu phone experience (not including the Linux kernel of course). This allows them to license it to manufacturers with a non-open/proprietary license. (Remember that contributing to canonical-owned code requires you to sign a CLA)

So?
They have every right to do that. Be thankful that they are opening the code up.
Even Google does the exactly the same thing with Android. Why does only Canonical get all the hate. This is something which they have to do if they want to survive in the mobile industry.