Open-link misbehavior
by Dimi Paun
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.
18 years, 1 month
stateless linux, and read-only root
by Bill Nottingham
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
18 years, 1 month
Re: The Strengths and Weakness of Fedora/RHEL OS management
by Jon Nettleton
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
18 years, 1 month
Re: GUI controls for instrumentation
by Joe Desbonnet
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
>
18 years, 1 month
Re: GUI controls for instrumentation
by Joe Desbonnet
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
>
18 years, 1 month
firstboot system maintenance task
by Florin Andrei
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/
18 years, 1 month
Fedora core for the Itanium
by Jason Connor
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
18 years, 1 month
pup uncheck all
by Eric Mesa
-----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-----
18 years, 1 month
smbfs not in the FC5 kernel?
by Jörn Rink
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.
18 years, 1 month
Re: FC5: first impressions
by Ron Yorston
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
18 years, 1 month