I'm somewhat interested in the answers to a few questions, after watching some of the discussion on the list. Now, seriously:
1) Is there sufficient interest in having the system-config packages split into data and GUI components so there might be Qt/KDE versions in the future?
2) If so, would people be more interested in it integrating into the KControl menu, or into a separate menu (system-control-center)?
'Cause I happen to really like writing in Qt, and I'll do it if there's sufficient interest in the idea.
On 4/12/07, Kelly lightsolphoenix@gmail.com wrote:
I'm somewhat interested in the answers to a few questions, after watching some of the discussion on the list. Now, seriously:
- Is there sufficient interest in having the system-config packages split
into data and GUI components so there might be Qt/KDE versions in the future?
-1 : subjectively wasted time and resources, doubled work, negligible benefit
- If so, would people be more interested in it integrating into the KControl
menu, or into a separate menu (system-control-center)?
+1 : if this _must_ be done, or if the votes say "yay", at the very least it should be done under KControl
'Cause I happen to really like writing in Qt, and I'll do it if there's sufficient interest in the idea. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox!
Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Apr 12, 2007 at 06:11:12PM -0400, Kelly wrote:
- Is there sufficient interest in having the system-config packages
split into data and GUI components so there might be Qt/KDE versions in the future?
I don't know about "sufficient", but there's interest in doing that for privilege-separation reasons. Being able to use alternate front-ends comes for free.
On Thu, 2007-04-12 at 20:50 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 06:11:12PM -0400, Kelly wrote:
- Is there sufficient interest in having the system-config packages
split into data and GUI components so there might be Qt/KDE versions in the future?
I don't know about "sufficient", but there's interest in doing that for privilege-separation reasons. Being able to use alternate front-ends comes for free.
Exactly. And moving the back-ends to somewhere central (e.g. fd.o) and adding the front-ends to the actual desktop projects (e.g. GNOME, KDE) is what we really want. That way we get all the distros/OS's to rally around the same code base and the user experience as a whole becomes better and more integrated.
That's already been happening with all the HAL/NetworkManager/GNOME's Project Utopia/KDE's Solid stuff and we're only going to do more of this in the future; not less. With some of the PolicyKit stuff I talked about
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01211.html https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01212.html
it will be, for example, a patch around 100-200 lines to GNOME's clock applet to provide the same functionality we today have in system-config-date. And it won't have to run as root; we can configure it such that laptop users don't have to auth, admins can lock it down, yadayada etc. etc. etc.
(The good thing, also, is that most of the hard work on PolicyKit is already done [1]; I plan to land it early in the Fedora 8 cycle and then go on a spree to integrate it with GNOME where applicable.)
So, in other words, I guess I'm saying that at least my point of view is that much system-config-* is a dead-end for all but really Fedora centric stuff that don't apply to other distros/OS'es. So my advice to people asking if it's a good idea to write Qt front-ends would be to start helping out on integrating these features in the respective desktop environments.
Of course, this task is a lot harder than doing s/GTK+/Qt/ to some source code; it actually requires that you come up with an architecture and design that can work on all distros and don't do silly things like running X11 apps as root. But I think in the end, it's a lot more rewarding doing this than just Qt-ifying code; I think it also helps create a better user experience.
(Also, a bunch of system-config-* stuff is RH/Fedora/CentOS centric (pup, pirut, SELinux stuff (to a degree)) and that's fine. We don't have to (and we don't want to either) do everything at once.)
Anyway, that's pretty much my position. Hope this helps.
David
Hi,
On Thu, 2007-04-12 at 23:00 -0400, David Zeuthen wrote:
On Thu, 2007-04-12 at 20:50 -0400, Matthew Miller wrote:
On Thu, Apr 12, 2007 at 06:11:12PM -0400, Kelly wrote:
- Is there sufficient interest in having the system-config packages
split into data and GUI components so there might be Qt/KDE versions in the future?
I don't know about "sufficient", but there's interest in doing that for privilege-separation reasons. Being able to use alternate front-ends comes for free.
Exactly. And moving the back-ends to somewhere central (e.g. fd.o) and adding the front-ends to the actual desktop projects (e.g. GNOME, KDE) is what we really want. That way we get all the distros/OS's to rally around the same code base and the user experience as a whole becomes better and more integrated.
This partly relies on all distros actually wanting to use the same codebase ;-P, I don't take that as a given. Has some potential for NIH syndrome.
That's already been happening with all the HAL/NetworkManager/GNOME's Project Utopia/KDE's Solid stuff and we're only going to do more of this in the future; not less. With some of the PolicyKit stuff I talked about
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01211.html https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01212.html
it will be, for example, a patch around 100-200 lines to GNOME's clock applet to provide the same functionality we today have in
I take it that you mean 100-200 lines of glue code in addition to the (not yet) separate frontend and backend that communicate via dbus? Because frankly I'd be seriously amazed if the functionality in s-c-date could be replicated with so few code.
system-config-date. And it won't have to run as root; we can configure it such that laptop users don't have to auth, admins can lock it down, yadayada etc. etc. etc.
(The good thing, also, is that most of the hard work on PolicyKit is already done [1]; I plan to land it early in the Fedora 8 cycle and then go on a spree to integrate it with GNOME where applicable.)
So, in other words, I guess I'm saying that at least my point of view is that much system-config-* is a dead-end for all but really Fedora centric stuff that don't apply to other distros/OS'es. So my advice to people asking if it's a good idea to write Qt front-ends would be to start helping out on integrating these features in the respective desktop environments.
Having UI and logic better separated would actually make it easier to bring back meaningful text/command line apps which is a good thing.
Of course, this task is a lot harder than doing s/GTK+/Qt/ to some source code; it actually requires that you come up with an architecture and design that can work on all distros and don't do silly things like running X11 apps as root. But I think in the end, it's a lot more rewarding doing this than just Qt-ifying code; I think it also helps create a better user experience.
Nils
On 04/13/2007 01:11 AM, Kelly wrote:
I'm somewhat interested in the answers to a few questions, after watching some of the discussion on the list. Now, seriously:
- Is there sufficient interest in having the system-config packages split
into data and GUI components so there might be Qt/KDE versions in the future?
+1 even +2 if a plain-text (ncurses) aka -tui interface is always available
- If so, would people be more interested in it integrating into the KControl
menu, or into a separate menu (system-control-center)?
I for one tend to avoid usually KControl. It is already way too large, looking more and more like a more-graphical-regedit. But most of the people I know do use it, so it seems like a good option.
--- Kelly lightsolphoenix@gmail.com wrote:
I'm somewhat interested in the answers to a few questions, after watching some of the discussion on the list. Now, seriously:
- Is there sufficient interest in having the system-config packages
split into data and GUI components so there might be Qt/KDE versions in the future?
I for one really like the idea, with one extra caveat- Make sure there is also a good batch/commandline (read: scriptable) backend in addition to one or more GUI backends, and possibly a curses-ish text based one as well. (but my focus is on being able to easily control any functionality from a bash script).
Having a good demarcation between commandline providing functionality, and GUI providing user interface for non hacker-typists, would be my approach to the matter. 0.02...
-dmc/jdog
____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
Jane Dogalt jdogalt@yahoo.com writes:
I for one really like the idea, with one extra caveat- Make sure there is also a good batch/commandline (read: scriptable) backend in addition to one or more GUI backends, and possibly a curses-ish text based one as well. (but my focus is on being able to easily control any functionality from a bash script).
+1
This is the point which should be stressed a lot -- I mean, still the main customers of RH are on server side and inability to use some tools without installing gnome (ehm, ehm, gnome-power-manager) seriously hurts. I know this is fedora list, but still there are some people who use Fedora-based distros on servers, right?
Best,
Matej
On Fri, 2007-04-13 at 09:42 +0200, Matej Cepl wrote:
without installing gnome (ehm, ehm, gnome-power-manager) seriously hurts
So install nut, acpid and cpufreqd and edit the configuration files yourself. You can't get the point-at-click power saving without some sort of desktop environment.
Or have I missed the point?
Thanks.
Richard.
On 4/13/07, Richard Hughes hughsient@gmail.com wrote:
So install nut, acpid and cpufreqd and edit the configuration files yourself. You can't get the point-at-click power saving without some sort of desktop environment.
Don't need to be so harsh Richard, if done right with a nice D-Bus API a policy enforcing daemon can be pretty much scriptable or configured from an init script as asked as well as used from any other kind of UI. It may be an utopian view but we will get there, yay :-)
Rui
On Fri, 2007-04-13 at 11:56 +0100, Rui Tiago Matos wrote:
On 4/13/07, Richard Hughes hughsient@gmail.com wrote:
So install nut, acpid and cpufreqd and edit the configuration files yourself. You can't get the point-at-click power saving without some sort of desktop environment.
Don't need to be so harsh Richard
Ohh, it wasn't meant to be harsh, sorry if it came out like that.
if done right with a nice D-Bus API a policy enforcing daemon can be pretty much scriptable or configured from an init script as asked as well as used from any other kind of UI. It may be an utopian view but we will get there, yay :-)
I'm not sure what policy you would want to script really. DPMS is likely set to off, you don't have lids on servers, and you really don't want a server auto-suspending on idle :-)
You can't also change the brightness, and makes little sense to run a server with laptop-mode. You probably don't want a server to immediately power off or hibernate when you press the power button, so I'm really not sure what a server version of g-p-m would do...
Richard.
Le Ven 13 avril 2007 13:07, Richard Hughes a écrit :
You can't also change the brightness, and makes little sense to run a server with laptop-mode. You probably don't want a server to immediately power off or hibernate when you press the power button, so I'm really not sure what a server version of g-p-m would do...
You want to set frequency scalling, do temp monitoring, etc
Also no GUI != no display, a PVR box has no general-purpose desktop UI but does video output, has a specialized video control UI, needs to set power button policy, etc
On Fri, 2007-04-13 at 13:21 +0200, Nicolas Mailhot wrote:
You want to set frequency scalling, do temp monitoring, etc
g-p-m doesn't do temperature monitoring. I have an open feature enhancement bug open, but I'm not sure if it really belongs in the scope of g-p-m.
Also no GUI != no display, a PVR box has no general-purpose desktop UI but does video output, has a specialized video control UI, needs to set power button policy, etc
Yes. There's work going on for a sort of g-p-m framework for embedded devices (OLPC, OpenMoko type stuff) which will probably apply for PVR boxes too. I did a talk about embedded devices at fosdem, and we might actually have something concrete at the end of the summer. Check out http://ohm.freedesktop.org/wiki/ for ideas we have so far.
Big note; you won't be using OHM on a laptop or desktop, session deamons are much more suited for that. OHM will just be for embedded devices.
Richard.
Le Ven 13 avril 2007 13:33, Richard Hughes a écrit :
Big note; you won't be using OHM on a laptop or desktop, session deamons are much more suited for that. OHM will just be for embedded devices.
Where do boxes that do NAT/mail filtering/PVR stuff 24/24 7/7, and double as occasionnal desktop¹ fit in ? I have one at home
¹ aka multi-purpose CABLE/ADSL end-point computer
On Fri, Apr 13, 2007 at 11:56:20AM +0100, Rui Tiago Matos wrote:
Don't need to be so harsh Richard, if done right with a nice D-Bus API a policy enforcing daemon can be pretty much scriptable or configured from an init script as asked as well as used from any other kind of UI. It may be an utopian view but we will get there, yay :-)
I wrote a daemon that responds to hal events (http://www.environnement.ens.fr/perso/dumas/halevt.html), used in combination with acpitool, maybe it could do the work. There is also ivman which does something similar than halevt.
-- Pat
On Fri, 13 Apr 2007 09:42:53 +0200, Matej Cepl wrote:
Jane Dogalt jdogalt@yahoo.com writes:
I for one really like the idea, with one extra caveat- Make sure there is also a good batch/commandline (read: scriptable) backend in addition to one or more GUI backends, and possibly a curses-ish text based one as well. (but my focus is on being able to easily control any functionality from a bash script).
+1
This is the point which should be stressed a lot -- I mean, still the main customers of RH are on server side and inability to use some tools without installing gnome (ehm, ehm, gnome-power-manager) seriously hurts. I know this is fedora list, but still there are some people who use Fedora-based distros on servers, right?
Best,
Matej
+1
Yes, lot of people seems to be using Fedora for servers. I agree the problem of config tools has to be re-approached. Distinction between backend and front-ends is desired.
I have my own lame view how this should be approached, I regret if some might not agree because I am just a tech guy I hope someone else can improve on it.
+ s-c-* tools have been done very well over the years + the development of s-c-* further should consider a backend and frontends in: -> Gnome -> KDE/Qt -> NCurses -> Web?
* More or less we have discussed, but web frontend is what I cite as more important. Once we have a backend in place, building a web based front end is always quick and easy, that also helps speed up development and testing. I believe there are various other advantages of such a development trend for s-c-*
* I dully notice it might not be appropriate for every s-c-* tool to have a web front-end, maybe someone else can help share their vision on this point.
* This will also require a daemon to host s-c-* tools on a Fedora host, maybe something can be figured out ?
This all might sound like webmin kind of approach but I consider s-c-* tools have worked very well and neat than webmin, besides that, fresh ideas can do better. I had this in mind for a long while and I just felt sharing it across on this thread.
Le mardi 29 mai 2007 à 19:57 +0000, Anuj Verma (Kevin) a écrit :
- s-c-* tools have been done very well over the years
- the development of s-c-* further should consider a backend and
frontends in: -> Gnome -> KDE/Qt -> NCurses -> Web?
You'd have to be real careful the frontends were kept synced too. Having to install GNOME libs may hurt, but having to maintain several sets of admin doc because the frontends have different capabilities would hurt more.
People only have to be hit a few times by missing stuff in one frontend to stop considering it at all. Admins may like the idea of a Qt/NCurses/whatever frontend but they are practical people and will take the complete primary upstream frontend over it any day.
On 5/29/07, Anuj Verma (Kevin) kevin.verma@gmail.com wrote: [ snip ]
- s-c-* tools have been done very well over the years
- the development of s-c-* further should consider a backend and
frontends in: -> Gnome -> KDE/Qt -> NCurses -> Web?
-1
I simply do not think it is a good idea to segment energies so much for so little gain. I like KDE/Qt, but I also like that the s-c-* tools are in the simple to use pygtk.
If someone is willing to do all this work seperate backend from frontend, and create the 4 frontend, more power to him, go ahead. But I don't think "Fedora" should divert resources to this goal. All I ask is that the tools not require gnome packages.
On Tuesday, May 29, 2007 10:16 pm Arthur Pemberton wrote:
I simply do not think it is a good idea to segment energies so much for so little gain. I like KDE/Qt, but I also like that the s-c-* tools are in the simple to use pygtk.
Personally, I'm not a fan of Python. It seems that every time someone writes a complicated program in it, the program winds up slow and unmanageable. If I were going to rewrite s-c-*, I'd probably do it in C/C++ this time around; if the code's going to be complex and hard to work with, at least get the speed advantage...
--- "Anuj Verma (Kevin)" kevin.verma@gmail.com wrote:
On Fri, 13 Apr 2007 09:42:53 +0200, Matej Cepl wrote:
Jane Dogalt jdogalt@yahoo.com writes:
I for one really like the idea, with one extra caveat- Make sure
there
is also a good batch/commandline (read: scriptable) backend in
addition
to one or more GUI backends, and possibly a curses-ish text based
one
as well. (but my focus is on being able to easily control any functionality from a bash script).
+1
This is the point which should be stressed a lot -- I mean, still
the
main customers of RH are on server side and inability to use some
tools
without installing gnome (ehm, ehm, gnome-power-manager) seriously hurts. I know this is fedora list, but still there are some people
who
use Fedora-based distros on servers, right?
Best,
Matej
+1
Yes, lot of people seems to be using Fedora for servers. I agree the problem of config tools has to be re-approached. Distinction between backend and front-ends is desired.
I have my own lame view how this should be approached, I regret if some might not agree because I am just a tech guy I hope someone else can improve on it.
- s-c-* tools have been done very well over the years
- the development of s-c-* further should consider a backend and
frontends in: -> Gnome -> KDE/Qt -> NCurses -> Web?
- More or less we have discussed, but web frontend is what I cite as
more important. Once we have a backend in place, building a web based front end is always quick and easy, that also helps speed up development and testing. I believe there are various other advantages of such a development trend for s-c-*
- I dully notice it might not be appropriate for every s-c-* tool to
have a web front-end, maybe someone else can help share their vision on this point.
- This will also require a daemon to host s-c-* tools on a Fedora
host, maybe something can be figured out ?
This all might sound like webmin kind of approach but I consider s-c-* tools have worked very well and neat than webmin, besides that, fresh
ideas can do better. I had this in mind for a long while and I just felt sharing it across on this thread.
Just for the record, my brain wasn't working the day I posted that original thing, and obviously I switched the meanings of frontend(ui) and backend(actual system modifier to reflect new config choices).
I do like the idea of standardizing everything, and having a webmin(ish) GUI _frontend_ to everything, as well as purely scriptable commandline frontend (and the eye candy native desktop gtk frontend).
It was mentioned that multiple frontends would be problematic due to them losing sync and supporting more or less features. Obviously if that were allowed to happen, the whole thing is a bad idea. IMO the way to keep it a good idea, is to _enforce_ all the front ends exposing _all_ of the functionality.
I.e.
$ system-config-X --help
would _by definition_(enforced policy) show you how to use all possible functionality from the commandline (or if its really a ton of stuff, maybe a 'try --manpage for full usage').
Then, I would expect all other frontends to be required to expose all of that functionality. Perhaps in a primitive way ala firefox's about::config. But all there in some form nonetheless. (i.e. the GUIs could be allowed to go nuts with eye candy UIs, but they must all have some brute force escape to a simple interface exposing all functionality, ala about::config).
Anyway, just my 2 cents. Mainly I just wanted to correct my frontend/backend butchery in the original quote, not that it appears to have corrupted the rest of the discussion.
-dmc/jdog
____________________________________________________________________________________Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/