devel March 2006

devel@lists.stg.fedoraproject.org

285 participants
295 discussions

Open-link misbehavior
by Dimi Paun 27 Mar '06

27 Mar '06

Hi folks, One more note in the focus handling saga. Right now, if one clicks on a link in Evolution, it is opened in the most recent Firefox window, as a new tab. This is fine, except when you have Firefox windows on different desktops. You click on a link in Evo, and then you start hunting on the various desktops completely blind trying to find it! (Unless you were lucky and the last used Firefox window was on the same desktop as your Evolution). Now, I can see why this behavior would be advantageous, as long as a _new_ window was opened in cases where the link would open on a tab on a different desktop. But as it stands, it is very confusing. I can see that technically the "right thing" would be hard to implement (it probably requires interaction between Firefox and the WM). So until we get this right, the default behavior should be to open a new Firefox window. Advanced user can select this other behavior knowing full well what they are getting into. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

8 14

stateless linux, and read-only root
by Bill Nottingham 27 Mar '06

27 Mar '06

For FC6 we're looking at bringing forward and integrating some of the Stateless Linux work. More detail will be up at: http://fedoraproject.org/wiki/StatelessLinux although probably not for a couple of days. One of the main tenets of this is that the system filesystems should be able to run read-only; there's no reason for apps to be writing to the system filesystem in general use. However, tracking this can be difficult; you don't want to force everyone to run read-only just to get data on their workloads. So, what we've worked on is a way to simply log what apps are writing to (or trying to write to) the system filesystems. This is now available at: http://people.redhat.com/notting/rolo/ A readme for this is attached. Basically, we're interested in getting logs from a variety of workloads, ranging from basic desktop to server; with this information, we can make sure that a readonly root scenario works for the majority of use cases that someone might want. Right now, reports can go to this list, in this thread or similar. If we need to set up a separate mechanism for recieving them, we can. Bill

3 4

Re: The Strengths and Weakness of Fedora/RHEL OS management
by Jon Nettleton 27 Mar '06

27 Mar '06

On Mon, 2006-03-27 at 15:39 -0500, sean wrote: > On Mon, 27 Mar 2006 12:33:50 -0800 (PST) > Shane Stixrud <shane(a)geeklords.org> wrote: > > > I find it hard to believe no one else sees the current > > complexity of system/application configuration as undesirable? Is > > this problem too big to be addressed? Is there too much historical > > precedence involved? Or is there a solid technical reason for not having > > a standardized configuration file format? > > > > Linux is perceived to be "difficult" to configure and managed by many, > > this is not because we lack guis and wizards, rather because one must > > discover the process each subsystem and application uses to > > accept configure directives from its users. > > > > I see no reason why it would not be possible and desirable to have a > > plain text compatible configuration file standard that is universal > > between subsystems, services and applications (besides it being a lot of > > work). It seems to me that the complexities of existing configuration > > tools (authconfig, system-config-samba etc...) are largely due to this > > same fundamental issue. > > GUI users don't want to be hunting through text files anyway, they > want nice settings windows and wizards. Anyone hand editing config > files better know what's going on anyway; the current situation isn't too > bad there. > > gconf already provides a reasonable way to change settings from the > command line and via GUI tools. What would you change? > > No matter what you come up with though, it will be many years before > you see wide spread adoption. If anything, you might consider a > project to create a system-wide config editor that knows all > the different formats etc and provides a consistent CLI/GUI > interface. > I started designing this type of system. A gui config editor/manager with it's own config languages, that used translator plugins for all the different config file formats out in the opensource community. It is really an ugly massive project, that is useless until you get all the translators written. The scariest problem that forced me to give it up was not just maintaining the translator plugins, but maintaining the translation rules for the different versions of config files for the same app. Just thought I would chime in. Jon

1 0

Re: GUI controls for instrumentation
by Joe Desbonnet 27 Mar '06

27 Mar '06

I would image that 3D effects (drop shadows, beveled edges etc) are possible. The downside of SVG is that it's all relatively new and products/libraries are not that common. If you are pitching to a conservative client (military type people for example) you don't want to take risks with the technology. Another thin client option I mentioned in an earlier post is VNC: you can run the application on the server and just use VNC protocol to update a VNC display. Ideal if the thin clients are on a high bandwidth LAN. If you want a fat client with portability: my personal preferences would be Java (SWT or Swing). It sounds like your application is going to be deployed on a controled environment, so I don't think Java would be a problem. If C++ is your language of choice I would agree with one of the previous posters -- you will not go wrong with Qt. Joe. On 3/27/06, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > On Monday, March 27, 2006 7:52 PM +0100 Joe Desbonnet > <jdesbonnet(a)gmail.com> wrote: > > > Advantage of SVG is that it's a thin client solution: ie you just need > > IE + SVG Plugin or just Firefox 1.5+ > > Does SVG do 3D? I tried a few of the examples and they all looked flat. > That's not a problem for me personally, but the PHB's love the pretty > gizmos, and that's who I'm shopping for. (I'm the guy who looks closely at > the screenshots in reviews to see what's actually happening, instead of > which has the prettier control set. For my own use, I buy for > functionality, not looks. Even in games.) > > -- > fedora-devel-list mailing list > fedora-devel-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list >

1 0

Re: GUI controls for instrumentation
by Joe Desbonnet 27 Mar '06

27 Mar '06

If your application needs an update rate of less than 1Hz (ie one second or more between updates) consider SVG: Take a look at these real time instrumentation demos from WPS Energy: http://www.wpsenergy.com/JayNick/default.asp Also: http://www.anomaly.org/wade/projects/instruments/Instruments.svg Advantage of SVG is that it's a thin client solution: ie you just need IE + SVG Plugin or just Firefox 1.5+ Joe. On 3/27/06, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Friday, March 24, 2006 8:33 PM -0700 "Lamont R. Peterson" > <lamont(a)gurulabs.com> wrote: > > > Trust me, I've written enough code in various languages and using various > > frameworks and toolkits to know that when you want stable, simple, > > reliable cross-platform code, Qt is excellent. > > I was looking at Qt. The developer license is pricey but probably doable. > What does it provide for the kinds of controls I mentioned? Do you know of > any demo apps I can look at that illustrate how well they function? > > As an example of the kind of app I'm thinking of, consider a model train > control panel which can control the speeds of various locomotives and > report track conditions in real time (eg. graphing the impedance of the > tracks). > > For an example of the kinds of controls I'm looking for, National > Instruments' Measurement Studio is an instrumentation GUI control library: > > <http://www.ni.com/mstudio/> > > And as you can see, there's no Linux port. > > > -- > fedora-devel-list mailing list > fedora-devel-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list >

2 1

firstboot system maintenance task
by Florin Andrei 27 Mar '06

27 Mar '06

After installing Fedora on any system, when the system boots up for the first time I always log in as root immediately, in a text-mode console (not via X), then run this sequence: killall anacron yum -y update yum clean packages anacron -nd sync reboot I just type everything in then I walk away and let the system do it since there should be no user interaction. Perhaps a better idea would be to run everything inside a typescript session, just to catch all the output for further analysis - hmmm, that actually does sound good, I should add that to my first boot ritual from now on. :-) Anyway, even before Fedora, I was pretty much doing the same thing, but translated in Red Hat Linux terms. Even before that, 10 years ago when I was using Slackware Linux :-) I was doing things that were functionally equivalent, albeit a lot more manual and hugely more cumbersome. I just think it's a good idea and it's the best and shortest way to build a clean and up to date system out of a fresh install. So I was thinking - perhaps it, or something equivalent - could be added as the last step to firstboot. Perhaps as a popup, informing the user that the system will apply all available updates, perform some maintenance tasks then reboot, and asking the user to either accept or reject it. The only snag that I can think of is Internet access - firstboot should test HTTP access and perhaps ask the user to configure proxy settings first (and skip this whole thing if there seems to be no way to enable Internet access at this point). Also, perhaps anacron should not even be started the very first time the system comes up after install, but instead wait for this maintenance task to be either accepted by the user (then the system will reboot and anacron will launch normally next time) or rejected (then perhaps anacron should be launched by firstboot). This might also help a lot of newbies since I noticed that some people running Linux for the first time are not aware of the necessity to apply updates and patches and do not even know how to do it. For the advanced users it would be just a convenient way to bring a fresh install up to date before actually pounding on it with real workload. Thoughts? -- Florin Andrei http://florin.myip.org/

4 5

Fedora core for the Itanium
by Jason Connor 27 Mar '06

27 Mar '06

Are there any plans for doing stable releases of fedora core for ia64? I've seen the rawhide tree for the platform, but with the recent pledges from intel, hp, and others to put more money into the platform, I think it might be time to release fedora for end users on it. -- Jason Connor "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." -- Alan Kay

5 6

pup uncheck all
by Eric Mesa 27 Mar '06

27 Mar '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pup sorely needs an uncheck-all button. Right now I have a few packages that keep messing the whole process up since they depend on Xorg6 (since the packagers haven't updated the specs yet) so it's quite tedious to uncheck every single box that won't work. Thanks, - -- Eric Mesa ericsbinaryworld(a)gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFEJaUBPvU+8ApmWXIRAn4JAJ9L24Z+O4wvfK4C4fSuZY3hIDxwUQCYjLHs uC++RLpQXzGflJVSi5cgOw== =pdCe -----END PGP SIGNATURE-----

3 2

smbfs not in the FC5 kernel?
by Jörn Rink 27 Mar '06

27 Mar '06

Hi, my old method to mount a smbfs filesystem does not work, further investigation shows, that the smbfs kernel module does not exist in the actual FC5 kernel. Has the method changed? In fedora core 3 there was such a kernel module.

5 5

Re: FC5: first impressions
by Ron Yorston 27 Mar '06

27 Mar '06

n0dalus wrote: >On 3/26/06, Ron Yorston <rmy(a)tigress.co.uk> wrote: >> >> If anyone needs a pre-release version of metacity with configurable new >> window focus I have it here: >> >> http://intgat.tigress.co.uk/rmy/metacity/fc5.html >> > >I'd be curious to see a description of how each behaviour acts. I know >some of the behaviours are listed on the Gnome bugzilla but there's a >lot to read there. > >I think other people would also be curious about what different >focusing styles exist in Gnome or will exist. My patch currently has two settings: "smart" which is the pre-2.14 behaviour and "strict" which enables the experimental strict focus approximation mode. (Neither of these is a particularly good name, as the smart mode isn't really smart and the strict mode isn't really strict.) The smart mode simply applies the user's current focus policy to new windows. So if you're using focus follows mouse and the new window appears at your mouse position it gets focus. Some people don't like this and claim it can be dangerous. The experimental strict focus approximation mode tries to prevent windows started from a hardcoded list of terminals from getting focus. In part it does this by putting the new window underneath the terminal, which lots of people find objectionable. In the GNOME Bugzilla Elijah Newren has suggested additional modes which might be called "always" and "never", though these haven't been implemented yet. I guess that "always" would force the new window always to have focus while "never" would never give focus to new windows. This latter is what some people would call "strict". All of these modes apply an additional layer of behaviour beyond what you currently get with the click/mouse/sloppy focus modes (and are independent of those modes). Ron

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2006