Announcement

Collapse
No announcement yet.

Ubuntu Planning To Develop Its Own File Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by Akka View Post
    So what do you use a file manager for?
    I thought people still used the terminal for the "real" work.
    Nautilus recursive search is perfect for movies, pdf doc, and ebooks. Everything else use the terminal.
    Since on the subject of Ubuntu i find the dash finds everything for me quickly enough

    A quick tap of the super key brings up the dash
    Type movie and all my .avi/.mp4/.flv/.webm/.wmv so on are instantly displayed no matter what folder
    If typing .doc all my .odt/.odp so on are displayed
    Being more specific and knowing the document/movies name and i get the result i am looking for instantly

    With this in mind and Canonicals vision of the dash finding anything anywhere. How much search functionality does the new filemanger actually need?

    Comment


    • #72
      Originally posted by rohcQaH View Post
      What do you think takes longer:
      a) paying their devs to help port dolphin to qml
      b) paying their devs to write a qml-based filemanager from scratch
      ?
      I pretty much agree with the rest of your post, but porting something to a different language and implementing it from scratch is pretty much the same amount of work, disregarding the (admittedly time consuming) design phase.

      Originally posted by tuubi View Post
      I think the problem lies deeper in the system than the file manager. I remember that fixing this required some fiddling back on older Xubuntu versions (I think the last one I tried was 12.10, can't say if it still had that problem), but it's worked fine out of the box on the last couple of Mint Xfce releases I've used. You'd most probably see the same thing with other graphical file managers unless you fix (or your distro fixes) the underlying problem.
      Yes, it's most likely like you said, but I didn't want to go to deep into the problem.
      mrugiero
      Senior Member
      Last edited by mrugiero; 02 February 2014, 09:10 AM.

      Comment


      • #73
        Originally posted by DDF420 View Post
        Since on the subject of Ubuntu i find the dash finds everything for me quickly enough

        A quick tap of the super key brings up the dash
        Type movie and all my .avi/.mp4/.flv/.webm/.wmv so on are instantly displayed no matter what folder
        If typing .doc all my .odt/.odp so on are displayed
        Being more specific and knowing the document/movies name and i get the result i am looking for instantly

        With this in mind and Canonicals vision of the dash finding anything anywhere. How much search functionality does the new filemanger actually need?
        Do it support regex? If not I think recoll have a a Unity plugin. Also Kde has a recoll plugin. Also to get regex search for KDE I think you can use nepoogle to search with regex directly in nepomuk database.

        Comment


        • #74
          Originally posted by mrugiero View Post
          I pretty much agree with the rest of your post, but porting something to a different language and implementing it from scratch is pretty much the same amount of work, disregarding the (admittedly time consuming) design phase.
          maybe. maybe not. Qt uses the MVC paradigm, and qml just replaces the V and parts of the C. Dolphin has a pretty good and well optimized M. If you read their blogs, you can appreciate just how much work is required for a good model.

          What irks me is that no words were lost to the feasability of adopting an existing solution. The mailing list post basically reads: "Now is a good time to gather requirements. And btw, we've already created a new project and written code."
          They skipped an important step there.

          Comment


          • #75
            Originally posted by rohcQaH View Post
            maybe. maybe not. Qt uses the MVC paradigm, and qml just replaces the V and parts of the C. Dolphin has a pretty good and well optimized M. If you read their blogs, you can appreciate just how much work is required for a good model.
            I stand corrected.

            What irks me is that no words were lost to the feasability of adopting an existing solution. The mailing list post basically reads: "Now is a good time to gather requirements. And btw, we've already created a new project and written code."
            They skipped an important step there.
            Oh, yeah, that bothers me a bit too, but I don't know, it's their time and money, I guess.

            Comment


            • #76
              Originally posted by xeekei View Post
              I'm actually surprised it took them this long. No one likes "GNOME Files". Personally I use Thunar, but it needs one or two more features before I'd call it perfect for me.
              No one? I like GNOME Files. And that's no joke. I've been using Linux for years now and Files is, for *my* tastes the best file manager out there. It's not perfect but it's more than good enough for me at least.

              Comment


              • #77
                Originally posted by ByteTraveller View Post
                For people that don't know yet SpaceFM (features, screenshots) is the spiritual successor to pcmanfm (via pcmanfm-mod). It can be made to look simple or ridiculously complicated, and is not developed in the recent 'fuck people who know what they are doing' style - the GUI is almost completely customisable and extendable (change menu items, add new ones, add new menu trees etc), launch your own scripts from whereever, plugin implementation along with a superior zenity clone to allow for an easy UI... I could go on and on.

                The programmer has taken it upon himself to avoid being tied as much as possible to other projects which he views with great suspicion such as GNOME and Red Hat things (e.g. udisks), so avoids GNOME dependencies and even wrote his own mount manager (udevil) when RH released udisks2 without backwards compatability to udisks1's interface or even the previous features available.

                SpaceFM is packaged in Debian.
                Thanks for coverage! Because, as you wrote it up as is, perhaps you can comment on the following:

                Originally posted by ByteTraveller View Post
                The programmer has taken it upon himself to avoid being tied as much as possible to other projects which he views with great suspicion such as GNOME and Red Hat things (e.g. udisks), so avoids GNOME dependencies and even wrote his own mount manager (udevil) when RH released udisks2 without backwards compatability to udisks1's interface or even the previous features available.
                Is backwards incompatibility of udisks2 with udisks1 - the primary reason for writing udevil?
                Because from what I get, they wrote udisks2 so it integrates with systemd services. And prior to that, udisks1 was using broken and depricated PolicyKit and ConsoleKit as authentication backends.

                How with udevil, I read following:

                Originally posted by http://ignorantguru.github.io/udevil/
                Set SUID
                After installing udevil, /usr/bin/udevil should have the suid bit already set. If not, set it like this
                I am pretty sure, working via SUID is exactly what PolicyKit+udisks and systemd+udisks2 are avoiding, hence dependencies.
                So why abadon a sane way of secure authentication and vote for SUID approach contributing to privilege escalation??

                Comment


                • #78
                  Originally posted by DDF420 View Post
                  With this in mind and Canonicals vision of the dash finding anything anywhere. How much search functionality does the new filemanger actually need?
                  Oh jeez... I hope they're not going to put Amazon results in the file manager.

                  Comment


                  • #79
                    about udevil

                    Originally posted by brosis View Post
                    Is backwards incompatibility of udisks2 with udisks1 - the primary reason for writing udevil?
                    Hi, I'm the developer of SpaceFM and udevil. Someone sent me this thread so I thought I would give a detailed answer while I'm here.

                    One reason I wrote udevil was because Red Hat developers were introducing unacceptable amounts of change into their tools and their API/CLI (including udisks and more), so it was unreliable to build upon them. They randomly decide to break everyone's work, frequently and unnecessarily. Breaking the udisks command line was just the latest example. Also, supporting udisks was taking too much time. Users were continuously having authentication and installation problems which would affect the file manager - it made device management broken half the time. udisks was and is a big problem area for file manager developers - it sucks time and causes instability. Since developing udevil, I deal with very few device support issues - much quieter. I can actually get other work done besides fixing Red Hat's problems.

                    Because from what I get, they wrote udisks2 so it integrates with systemd services. And prior to that, udisks1 was using broken and depricated PolicyKit and ConsoleKit as authentication backends.
                    ...
                    I am pretty sure, working via SUID is exactly what PolicyKit+udisks and systemd+udisks2 are avoiding, hence dependencies.
                    So why abadon a sane way of secure authentication and vote for SUID approach contributing to privilege escalation??
                    The SUID approach is relatively secure for most setups. pmount is another popular example of an SUID mount solution along the lines of udevil. The complexity and often breakage added by more complex authentication schemes simply isn't worth it to most users in practice. If they worked more reliably, that would be another matter. They can also LOWER security because users disable or misconfigure them just to get them working at all (I see this very frequently). The complexity also introduces more places for security to go wrong. I do not consider udisks a highly secure solution, especially having seen the quality of its source code and the general development practices.

                    SUID, if done well, is a reasonable approach here. udevil scrubs the environment and drops its root priviledges except when running needed commands, so almost all of its code is run as a normal user. You can also easily integrate additional authentication/notification scripts into udevil so it uses any method of authentication you choose, in addition to its extensive built-in mechanisms. Even if you do somehow manage to run udevil SUID when you're not supposed to, getting it to do something damaging is no small task either, as udevil.conf can lock its behavior down tightly.

                    udevil was written to be a reasonable, flexible and simple solution to mounting in Linux, free(r) of Red Hat's poor dev practices. It's not necessarily for everyone, but it quickly cures the complexity and breakage of udisks. udevil can also do more than udisks and pmount in some areas, and provides much more flexibility to a system admin.

                    The use of udevil is optional in SpaceFM. SpaceFM uses configurable commands for device mounting and unmounting, so you can use any command, including udevil, udisks v1, udisks v2, pmount, or others. It will automatically discover what you have installed and use that. So udevil isn't forced on anyone, it's another option available. SpaceFM only requires udev itself (or alternatively it still supports HAL as well).


                    As for Ubuntu's plans, I really don't think much of file managers being owned by DEs or distros. They tend to be hard-coded to one set of system tools, and development is less responsive to users. Obviously they need to use something, but I think more independent FMs offer more. Why limit your file manager to what the DE chose? (And thus also limit your selection of system tools.) Obviously I'm not unbiased, but SpaceFM excels at being able to use just about any system tools available, and builds and works on ancient systems (lenny, GTK 2.18, HAL) as well as the latest udev, udisks2 and GTK3. In short, it gives you lots of choices.

                    But obviously Ubuntu needs to choose something, and these days anything you can do to get away from Red Hat developers is a very good idea.

                    Comment


                    • #80
                      Originally posted by brosis View Post
                      Thanks a bunch!

                      Edit: So I predict, in 6-9 years, Gnome3 will be deprecated altogether, with developers switch to Cinnamon and working from there on.
                      i hope not as i hate the classical desktop concepts. they are bad. the only reason people are still sticking to them is because they are used to it.

                      Comment

                      Working...
                      X