Ubuntu's File Manager App Has A Long TODO List

[somini]

What are they doing? Why aren't they working TOGETHER with the KDE community? KDE has mechanisms for much of what they want, they just lack a QML facing interface to use them from within QML. The API's are there. Sure, it would probably require them to use KIO and some more KDE specific stuff, but it would be a win-win situation for both parties if canonical invests some time in making those KDE API's work properly on mobile devices with QML exposure. It would certainly be a much shorter development time then doing everything all over again (then again, canonical heavily suffers from the NIH syndrome).

To sum it up. KDE has the API's for the following points of their todo:

• all the places related stuff via kio
• extracting archives.. KArchive.
• SAMBA, NFS, FTP, etc.. KIO!
• Bookmarks: KBookmarks

Other points are merely QML based issues that is just a matter of using QML.

• keyboard shortcuts: plain QML, Action component
• multiple tabs
• drag/drop

I think it's clear what they need to do...

It's not like that's basic features of every desktop, such as Unity. It also works on Unity!
This is not a technical problem at all.

[Akka]

Sounds like they should just reskin Dolphin, which has all those features (and give its needed QML upgrade), rather than reinvent the wheel for the trillionth time.

Maybe I have misunderstood something. But I thought porting to qml was a almost complete rewrite? I think Qwidget is closer to Gtk than qml in how it works?

[TheBlackCat]

Maybe I have misunderstood something. But I thought porting to qml was a almost complete rewrite? I think Qwidget is closer to Gtk than qml?

Yes, the UI will probably need to be rewritten. But a lot of their TODO list involves things that are provided by the underlying frameworks and other libraries (like KIO) that will not have to be rewritten. Further, a QML UI is not a monolothic thing, it would probably have (for example) one or more file view components, which could be reused across components (actually, plasma already has a file view component). Same with stuff like a places panel or tabs, those can be shared. So although the details of the UI will probably be different, a lot of the code can be shared (and will be within KDE, there is a lot of work going on about getting the file manager-related stuff organized and abstracted so it works well across projects and with QML).

[mmstick]

Of course they are allowed to do whatever they want. Just like we are allowed to have an opinion on whether their decision is the best one. Of course they have the final say, but that doesn't mean we can't have our own opinions.

It quickly gets tiring to see the same naive banter on every little thing. Not only is throwing around opinions completely useless other than for contributing to loss of potential productivity due to writing those aforementioned pointless opinions, but stating the same opinion, in each of it's many narrow implementations, repeatedly isn't exactly helpful to any case -- even your own.

[TheBlackCat]

It quickly gets tiring to see the same naive banter on every little thing. Not only is throwing around opinions completely useless other than for contributing to loss of potential productivity due to writing those aforementioned pointless opinions, but stating the same opinion, in each of it's many narrow implementations, repeatedly isn't exactly helpful to any case -- even your own.

This is a forum. The whole point of a forum is to discuss things. If you don't want to read the discussion, then don't come.

[mmstick]

This is a forum. The whole point of a forum is to discuss things. If you don't want to read the discussion, then don't come.

This does not imply that such discussions on the aforementioned forum must degrade into childish nonsense.

[mhall119]

Riddle me this: what's wrong with them doing whatever they want with their developers on their time with their money? Why does everyone have to use the same APIs?

The developers aren't Canonical employees, they are community contributors working together with other Canonical teams.

What are they doing? Why aren't they working TOGETHER with the KDE community?

The developers chose use components from the Nemo Mobile project instead. We're not re-inventing the wheel here, we're just not using KDE's wheel.

[markg85]

This does not imply that such discussions on the aforementioned forum must degrade into childish nonsense.

The one who's posting the biggest nonsense thus far in this thread is you.

[markg85]

The developers aren't Canonical employees, they are community contributors working together with other Canonical teams.



The developers chose use components from the Nemo Mobile project instead. We're not re-inventing the wheel here, we're just not using KDE's wheel.

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?...

[mhall119]

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 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.

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.

Which is why we're re-using components when we can, such as Nemo's file manager, Konsole terminal widget, Poppler for pdf rendering, etc. The majority of the work we're doing is in the front-end, building convergence-capable interfaces with the Ubuntu UI Toolkit. That's not necessarily something you can just add as a patch to an upstream project.

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?...

I'm not sure what the Beryl reference is about, so I'll just respond to the Trojita bit. Canonical originally had no plans to develop our own native email client. However, we found that there were 3 or 4 separate efforts that started to build an Ubuntu UI Toolkit front-end on top of Trojita, so we got all of those people together for a meeting and they decided to not only combine their efforts, but to do it as part of upstream. So we created a new UI subdirectory for Ubuntu, updated the Cmake files to allow it to be built (Trojita already supported Qt4, Qt5 and Harmattan UIs), and got to work. Everyone was happy. Then we ran into issues where something that worked in the Qt4 or Qt5 interface wasn't exposed to QML to be usable in the Ubuntu interface (or, for that matter, the Harmattan one). Now we could change the core parts to make them available to QML, but doing so would require a change to the Qt4/Qt5 UI as well to make them work. 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.