Daniel Llewellyn schreef op 09-10-2016 21:37:
On 09/10/16 20:17, Daniel Llewellyn wrote:
On 09/10/16 19:53, Xen wrote: As a feature request that you could
try to get implemented by the gnome guys you could suggest to their
issue-tracker that gvfs support KIO-slaves. Also would be worth
suggesting to the KDE guys the inverse, for KIO to support
gvfs-mounts.
Having just read your other reply to Ralf, I wanted to say that I
don't mean to be saying "don't do the work, ask someone to do it for
you". Filing a feature request was a suggestion for those that don't
have the developer mindset. As you indicate you have such, I would
revise my suggestion to opening a dialog with the two teams,
individually, and detail your ambitions. Try to get them to assist you
in understanding their code-bases. Fork each of the systems and
implement the cross-polination, before asking for them to merge your
changes when you think it's ready.
Alternatively attempt to unify the two systems (licenses permitting)
into a single back-end and publish independently. Then send patches to
each of the projects to switch their front-ends to use your back-end.
Of course that could be a good path forward if that was the first thing
to do, thank you.
What I mean by that is that if you start creating a house and you talk
about a room people may tell you how to create the room but maybe you
are only discussing the room and you are still building the foundation
of your house, you see?
This automount stuff is not my primary objective as of today so I won't
be doing that but...
The first thing you do is to get your own systems working in a certain
way. It does not help if you have food in a month if you have to be
hungry today. So first my own systems must be in operating order in that
sense, you know.
Then when you have rudimentary levels of support and functionality you
start publishing these rudimentary things (or you were already doing
so).
Then at a certain point you may find that you cannot advance in your
functionality without going higher level and getting the cooperation of
other systems or people that already exist. But you must first have a
basis to start from: that rudimentary thing.
Rudimentary things require rudimentary systems so you first focus on
understanding them and getting those basic building blocks working
together as they should. That is why I say that high level functionality
is not much use because /a developer can't use them/.
You can't use bits and pieces of snaps to create something else. This is
hardly possible.
Systemd is both high and low level, annoyingly so.
And I have many different goals but as it stands you know what I've said
is that the problem is that the user has very little focus and the
system has a lot of it. And you must start to work across the spectrum
to move that in the direction of the user, a single system will not
suffice. And then you can get a more secure system because the
administrator becomes less used than the regular user.
See for me it is more about the broader concepts than working hard to
fix a single system in isolation. That is why I discuss this here, of
course. Or, at least, I hope to....
Because without a deeper understanding you cannot solve anything I
believe. And it also helps if other people also have that deeper
understanding before you start making anything, at least in isolation,
or at least with the idea that eventually they will turn around but you
have never spoken to them before? That doesn't work, you know it.
So I'm not gonna be some slave to their code bases ;-). No one should,
really, they have enough problems with it themselves already ;-). (You
should see what madness the plasma developers have to deal with -- (I
was on their list once)) -- and really I just feel everyone should just
do their own thing and that requires (being able to make use of)
building blocks. But if the bigger parties make it so that the building
blocks disappear, we have a problem.
And that is also perhaps why I am arguing here today: don't turn
everything into high-level things that have no components.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
