Mlterm installed with RTL languages
Hello, is it possible to have mlterm installed when some user install RTL language? it's know that gnome-terminal doesn't support Arabic or Farsi or any RTL language because of vte bug https://bugs.launchpad.net/vte/+bug/263822 however mlterm does, https://wiki.ubuntu.com/Mlterm thanks, -- 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
Re: Shooting for the Perfect 10.10 with Maverick Meerkat
Mark, Thanks for your support, my beef about wanting the basics to work still applies. However, I have spent a couple of hours sorting out the Scanner and Wi-fi and now both are working. It is all very well including SANE in the Applications menu but there should also be an appliaction in the same group indicating how to. With my Epson Scanner this was easy but meant visiting the Epson web site. The last time I had done this the only files available were tarballs and a manual on how to which would have taken some considerable time for me to get going which I haven't got. The downloads Epson now have are great. To my surprise when I turned on my Wi-Fi and set it up it worked too. Rather than program writers we need to get users to submit how-to pages along the lines of idiot user guides. It might then be possible for the programmers to add the whistles and flutes as well. On Thu, 2010-04-08 at 12:36 +0100, Mark Ellse wrote: > I would like to add my support to the comments by Bob. > > I am a very enthusiastic supporter of Ubuntu. I am grateful for all > that Canonical and Mark Shuttleworth have done for the whole linux > community. But there is one thing that really doesn't help - the > glossy spin, compared with the nitty gritty of addressing those things > that really stand in the way of Ubuntu and linux adoption. Here are > two examples. > > 1. Jono writes: " We don’t just want to be connected to the internet, > we want to be connected to each other. Social from the Start is our > initiative to make the desktop a collaborative, social place." > > This is politician speech and it gets things nowhere. I wrote to Jono > a month ago asking if the bug making Lucid and Karmic unusable on many > Intel graphics boards (Bug 456902) is getting any Canonical attention. > It's a bug that totally wrecks Ubuntu for so many users. > > I know it's an upstream issue. I know that we are all far too busy and > we can't do everything, but no reply to simple questions like this is > very discouraging. It makes you feel that Canonical are just like our > politicians - they spout eloquently but have their own agenda and are > pretty much indifferent to what the man in the street actually > thinks. > > I run a school where there are now a lot of linux machines. If I were > confident of the support, all but a half a dozen would be linux. But I > am not confident of the support. > > A little while ago I wrote to Canonical asking about paid support. At > the time we were having problems with Ubuntu machines failing to > browse a Windows peer-to-peer network. You can see from the bug report > how significant this, and related bugs, have been. > > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/207072 > > I wrote a simple letter asking "If I pay for support, will you be able > to help me solve this problem?" to which I had no clear reply. I > pushed the point. > > "> Really, I do need some information about whether Ubuntu is aware > of, > > and active in dealing with, this bug and can give a reasonable > > prediction about the possibility of fixing it. If so, I am very > happy > > to part with pennies, either in direct support fees, or sponsoring a > > fix. > > I don't know the specifics of your bug so can't really comment. And > I'm > certainly not offering a guarantee that for 1400 GBP we're going to > fix > every bug you have in an operating system consisting of millions of > lines of code. > > What I can tell you is that your support subscription means that bugs > that effect you will get more attention." > > > I'm sorry, but such a "politician's" answer won't help. If Ubuntu > users are going to trust Canonical - and those of us who use Ubuntu > are tremendously positive towards what Canoncial are doing and do want > to support it - then Canonical has to improve the way that it > communicates with the community. > > 2. Forever we are told about the glossy future rather than the > practical present. About "the perfect 10" Jono says " we’ll have a new > design track, and a “cloud and server” track". > > This sounds great. But there is a big hole in the the general Ubuntu > provision with the lack of a simple server. At my school we use SME > server (www.contribs.org), which is a simple to set up as an Ubuntu > workstation. But it can't handle the authentication for linux machines > on the network (though it is an excellent file/proxy/almost everything > else server). The lack of an "out-of-the-box" server solution to work > with both Ubuntu and Windows workstations is a great disadvantage. > > This is not rocket science. It is not new ground. It won't produce > great headlines and reams of oratory from Jono like " This is a time > of great innovation and change in the Linux world, with major new > initiatives from powerful groups bringing lots of new ideas, new > energy and new code." But, in the end, it is simple, clear practical > solutions to these problems that will make linux mainstream.
just a heads up to the developers on bluetooth mouse losing pairing
I'm only on this list because I am intimidated by launchpad. i'm running lucid, and the gnome screensaver was set to ask for my password again overnight. i noticed though that after this long of time, my bluetooth mouse lost its pairing. i happen to have a wired mouse connected to the same, so all was not lost. i'm however in gnome now, and the bluetooth mouse still is not communicating with my bluetooth dongle. i have bluez and bluez-util installed. the bluetooth adaptor is white in a always on and listening (enabled) mode but the connection is definitely lost. thanks for listening. Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5-- 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
Re: Thoughts on quitting and window controls
On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall wrote: > On Tue, Apr 6, 2010 at 8:39 PM, Jonathan Blackhall > wrote: >> It's very confusing for me when I click the big 'X' in my window controls, >> only to find that the application I was attempting to close has since been >> minimized to my system try (or notification area or its respective indicator >> applet or wherever it goes instead of quitting). Examples of programs with >> this behavior include Rhythmbox and Empathy in the default install. To me, >> the 'X' signifies closing and quitting the application. If I wanted to >> minimize it and keep it open, I would think to click the 'Minimize' button >> before clicking the 'X'. In fact, I'd argue that the only reason anyone >> thinks this is appropriate is because it's what's been done in the past. >> The reason I find this so frustrating is because in order for me to eXit an >> application, I have to go searching through menus (File->Quit) or know some >> fancy keyboard shortcuts (things that casual users never even think about). >> >> I can only assume that developers' theories behind this (which is definitely >> not a problem unique to Ubuntu) stem from them telling themselves that no >> one would actually want to Quit their application. "What they *really* mean >> to do is close the window, but keep the application running silently. So >> I'll just save them the trouble of accidentally quitting by changing the >> function of that 'X' button." I just dislike the fact that it sends mixed >> signals. After all, if I click 'X' in Firefox or in gEdit or in a whole >> host of other applications, I'm quitting and completely closing it. Why >> must this be different in Rhythmbox? And also, when I install a new >> application, what is the 'X' going to do when I click it in this >> application? >> >> I'm not exactly sure what I'd propose to fix this problem. I really just >> think that the current way is broken. Maybe the function could be switched >> to the Minimize button, but that would likewise exhibit ambiguity, although >> I'd argue less so than the current incarnation. Maybe there should be a new >> window button, but that doesn't seem like a very elegant solution either. I >> thought about filing this as a bug, but then I thought it might be better to >> generate discussion amongst developers. What are your thoughts? Do you >> consider the current situation a problem? If so, what do you propose to fix >> it? >> >> Cheers, >> Jonathan >> >> -- >> 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 >> >> > > I chewed on this thought for a bit, and I think adding a "really > close" button to a window would compromise what is _potentially_ a > pretty well thought out bit of UI. That's not to say it is well > thought out yet, but I think it could be! > > Conventionally, a window represents some thing the user is doing, so > closing it should close that thing. A toplevel window is almost always > something the user has directly triggered and is directly, > purposefully interacting with, and I don't think we have anything else > in the desktop that fits that role. Therefore, if the act of closing a > window is affecting anything more than what that window is > representing, something has gone wrong and should be fixed. For most > web browsers, we're fine; the close button closes the web page > associated with that window, but the application, other web pages and > any current downloads (should) keep running. > > The rest is naturally fed by the “Just Works” philosophy; if a process > is not providing anything, it should become irrelevant (probably by > exiting). Firefox does this for you all the time. A lot of developers > think of it as a robotic "all window are closed, so exit" deal, but I > think it's more "we are no longer serving a purpose, so exit." > Applications should track what they are doing for the user to decide > whether they are wasting memory. > > Windows are remote controls for resources. In the case of Tomboy, > that's a note. (When you close a window in Tomboy, you aren't > destroying the note!). For Empathy, that's an instant messaging > account (Telepathy). When you close the buddy list, it doesn't log you > out, but you can open the buddy list and tell it to log you out. (In > this case that's technically the case, too; Telepathy, Empathy, etc. > are split into a whole pile of small, detached programs that run for > different purposes). > > Rhythmbox is a different example, but let's try to fit it under the > same theory. It already mostly does. The Rhythmbox main window is for > controlling what music the Rhythmbox "service" (represented by its > indicator icon) is playing. It just happens that the Rhythmbox service > is, technically, the same process as the Rhythmbox main window. Users > don't care about that, though. > Someone opens Rhythmbox to
Re: Thoughts on quitting and window controls
Evan wrote: > On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall > wrote: >> I chewed on this thought for a bit, and I think adding a "really >> close" button to a window would compromise what is _potentially_ a >> pretty well thought out bit of UI. That's not to say it is well >> thought out yet, but I think it could be! >> >> Conventionally, a window represents some thing the user is doing, so >> closing it should close that thing. A toplevel window is almost always >> something the user has directly triggered and is directly, >> purposefully interacting with, and I don't think we have anything else >> in the desktop that fits that role. Therefore, if the act of closing a >> window is affecting anything more than what that window is >> representing, something has gone wrong and should be fixed. For most >> web browsers, we're fine; the close button closes the web page >> associated with that window, but the application, other web pages and >> any current downloads (should) keep running. >> >> The rest is naturally fed by the “Just Works” philosophy; if a process >> is not providing anything, it should become irrelevant (probably by >> exiting). Firefox does this for you all the time. A lot of developers >> think of it as a robotic "all window are closed, so exit" deal, but I >> think it's more "we are no longer serving a purpose, so exit." >> Applications should track what they are doing for the user to decide >> whether they are wasting memory. >> >> Windows are remote controls for resources. In the case of Tomboy, >> that's a note. (When you close a window in Tomboy, you aren't >> destroying the note!). For Empathy, that's an instant messaging >> account (Telepathy). When you close the buddy list, it doesn't log you >> out, but you can open the buddy list and tell it to log you out. (In >> this case that's technically the case, too; Telepathy, Empathy, etc. >> are split into a whole pile of small, detached programs that run for >> different purposes). >> >> Rhythmbox is a different example, but let's try to fit it under the >> same theory. It already mostly does. The Rhythmbox main window is for >> controlling what music the Rhythmbox "service" (represented by its >> indicator icon) is playing. It just happens that the Rhythmbox service >> is, technically, the same process as the Rhythmbox main window. Users >> don't care about that, though. >> Someone opens Rhythmbox to control the playing music (to pause it or >> play it), then closes it when that is done and the service goes on in >> the background. If the music is stopped and Rhythmbox's controller is >> closed, Rhythmbox has no reason to continue running, so the process >> should exit. That should have absolutely no impact on the surrounding >> user interface, however. >> >> The Problem: that does have a strange impact on the surrounding user >> interface. Particularly strange for Rhythmbox, since the indicator >> serves as a launcher for the controller. Unless we want that Rhythmbox >> indicator to be permanent, it always will create a bizarrely >> shape-shifting desktop within the current design. It always will with >> a "really close" button, too, because "really closing" the window will >> kill the Rhythmbox service and, therefore, the indicator applet. >> Consider the inconsistency at hand from a lower level: killing the >> Rhythmbox process kills its indicator, its controller, and the music. >> Killing the Empathy process kills the buddy list but maintains your >> accounts as they are and the message indicator. Killing Evolution >> does not delete your email (unless you were having a good day; it gets >> jealous). >> >> Good news, in my books: gnome-shell has launchers and running >> applications in the same place ;) >> That is a more profound improvement than mere cosmetics. It means >> things don't move unexpectedly. Personally, I want to be able to >> reliably head to wherever I start applications and open my Buddy List, >> unconcerned with whether a process called "empathy" was already >> running, and I want to do that as quickly as heading to the message >> indicator and opening my Buddy List from it. I want to do that because >> the same functionality fits for anything, not just instant messaging; >> from notes to music to calendars and todo lists. >> We can either have a specialized launcher in the top panel for every >> single type of desktop service, or we can have a smarter application >> launcher. >> >> PS: Granted, my chewing on this was in the midst of a billion things >> happening at once, so I realize I may be coming across as a complete >> lunatic. > > Mind-boggling: yes. Lunatic: not necessarily :) > > If I'm understanding you properly, the user should have no concept of > services or processes. There is a single list of all applications, > whether they are running with a window, running as a service, or not > running at all. > When the user clicks on an application which is not running, or > running as a service, then the c
Re: Thoughts on quitting and window controls
Brandon Kuczenski wrote: > Derek Broughton wrote: >> John McCabe-Dansted wrote: >> >>> Maybe. But the paradigm isn't really that pressing the Close >>> button minimizes the window to the systray. >> >> I beg to differ. Think as a user, not a developer. I submit that >> _users_ do not generally understand a difference between minimizing to >> the tray or the task bar - except that they know something minimized to >> the task bar is taking up more space. >> >>> The paradigm is that closing a >>> window closes that window *and* that closing a window never closes a >>> service. >> >> Again, I disagree. Users think "close" and don't stop to think... >> >>> I think most people would be confused if e.g. clicking close on >>> the main sound preferences dialog stopped the sound server. >> >> ...what closing a sound server means. I think most people are confused >> by >> _any_ change to their system. [I'm confused by the fact that Firefox now >> has the ability to hang my entire machine, which it only started to do >> with >> the last upgrade] Yes, making the close button shut down a server and >> the minimize button minimize to either the task bar or the system tray >> _would_ be initially confusing but imo is more logical, and would be more >> intuitive. >> > > I think it's unwise to try to imagine a 'typical' user. I thought that was my point. We shouldn't be "imagining", we should actually be trying to figure out who the typical user is. > There are > [apparently] a great many people who like the way mac handles the > desktop environment- I have never been able to fathom it, but that's why > I don't use it. (among other reasons :P ) Mac users and Windows users > coming to Ubuntu will expect different things- but Ubuntu is something > else entirely I couldn't care less who Mac, Windows and Ubuntu users are - I just wish people were designing to some UI standard, and would hope that we had some analysis that would suggest a good direction for that standard. Instead, we have people designing any old UI that works for them, with human issues largely ignored. That way lies slavish imitation, not innovation. Whatever you think of the Mac interface (I can't fathom it either), it exists because Apple _knows_ that it works for a large number of people. -- derek -- 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
Re: Thoughts on quitting and window controls
On Fri, Apr 9, 2010 at 8:40 PM, Derek Broughton wrote: > Evan wrote: > >> On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall >> wrote: > >>> I chewed on this thought for a bit, and I think adding a "really >>> close" button to a window would compromise what is _potentially_ a >>> pretty well thought out bit of UI. That's not to say it is well >>> thought out yet, but I think it could be! >>> >>> Conventionally, a window represents some thing the user is doing, so >>> closing it should close that thing. A toplevel window is almost always >>> something the user has directly triggered and is directly, >>> purposefully interacting with, and I don't think we have anything else >>> in the desktop that fits that role. Therefore, if the act of closing a >>> window is affecting anything more than what that window is >>> representing, something has gone wrong and should be fixed. For most >>> web browsers, we're fine; the close button closes the web page >>> associated with that window, but the application, other web pages and >>> any current downloads (should) keep running. >>> >>> The rest is naturally fed by the “Just Works” philosophy; if a process >>> is not providing anything, it should become irrelevant (probably by >>> exiting). Firefox does this for you all the time. A lot of developers >>> think of it as a robotic "all window are closed, so exit" deal, but I >>> think it's more "we are no longer serving a purpose, so exit." >>> Applications should track what they are doing for the user to decide >>> whether they are wasting memory. >>> >>> Windows are remote controls for resources. In the case of Tomboy, >>> that's a note. (When you close a window in Tomboy, you aren't >>> destroying the note!). For Empathy, that's an instant messaging >>> account (Telepathy). When you close the buddy list, it doesn't log you >>> out, but you can open the buddy list and tell it to log you out. (In >>> this case that's technically the case, too; Telepathy, Empathy, etc. >>> are split into a whole pile of small, detached programs that run for >>> different purposes). >>> >>> Rhythmbox is a different example, but let's try to fit it under the >>> same theory. It already mostly does. The Rhythmbox main window is for >>> controlling what music the Rhythmbox "service" (represented by its >>> indicator icon) is playing. It just happens that the Rhythmbox service >>> is, technically, the same process as the Rhythmbox main window. Users >>> don't care about that, though. >>> Someone opens Rhythmbox to control the playing music (to pause it or >>> play it), then closes it when that is done and the service goes on in >>> the background. If the music is stopped and Rhythmbox's controller is >>> closed, Rhythmbox has no reason to continue running, so the process >>> should exit. That should have absolutely no impact on the surrounding >>> user interface, however. >>> >>> The Problem: that does have a strange impact on the surrounding user >>> interface. Particularly strange for Rhythmbox, since the indicator >>> serves as a launcher for the controller. Unless we want that Rhythmbox >>> indicator to be permanent, it always will create a bizarrely >>> shape-shifting desktop within the current design. It always will with >>> a "really close" button, too, because "really closing" the window will >>> kill the Rhythmbox service and, therefore, the indicator applet. >>> Consider the inconsistency at hand from a lower level: killing the >>> Rhythmbox process kills its indicator, its controller, and the music. >>> Killing the Empathy process kills the buddy list but maintains your >>> accounts as they are and the message indicator. Killing Evolution >>> does not delete your email (unless you were having a good day; it gets >>> jealous). >>> >>> Good news, in my books: gnome-shell has launchers and running >>> applications in the same place ;) >>> That is a more profound improvement than mere cosmetics. It means >>> things don't move unexpectedly. Personally, I want to be able to >>> reliably head to wherever I start applications and open my Buddy List, >>> unconcerned with whether a process called "empathy" was already >>> running, and I want to do that as quickly as heading to the message >>> indicator and opening my Buddy List from it. I want to do that because >>> the same functionality fits for anything, not just instant messaging; >>> from notes to music to calendars and todo lists. >>> We can either have a specialized launcher in the top panel for every >>> single type of desktop service, or we can have a smarter application >>> launcher. >>> >>> PS: Granted, my chewing on this was in the midst of a billion things >>> happening at once, so I realize I may be coming across as a complete >>> lunatic. >> >> Mind-boggling: yes. Lunatic: not necessarily :) >> >> If I'm understanding you properly, the user should have no concept of >> services or processes. There is a single list of all applications, >> whether they are running with a window, runn
any chances of including something like this still? :)
http://code.google.com/p/ubuntu-linux-video-wallpaper-dual-monitor/ i'd appreciate it if someone just took a look at it, i'm not asking to shove this into the lucid release or even the one after that. just wanted to make you aware of a hack i found ;) -- - Greetings from Rene7705, I have made some free open source webcomponents designed and written by me available through: http://code.google.com/u/rene7705/ , or http://mediabeez.ws (latest dev versions, currently offline) - -- 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
Re: just a heads up to the developers on bluetooth mouse losing pairing
I had _exactly_ the same thing happen to me. Must be some kinda cyberwar going on, coz for me, not only did my mouse & keyboard stop working, even my teradisk crashed! thankfully i have an offsite backup that i have now duplicated again to a brandnew teradisk... On Fri, Apr 9, 2010 at 5:24 PM, Arthur Rosene III wrote: > I'm only on this list because I am intimidated by launchpad. i'm running > lucid, and the gnome screensaver was set to ask for my password again > overnight. i noticed though that after this long of time, my bluetooth > mouse lost its pairing. i happen to have a wired mouse connected to the > same, so all was not lost. i'm however in gnome now, and the bluetooth > mouse still is not communicating with my bluetooth dongle. i have bluez and > bluez-util installed. the bluetooth adaptor is white in a always on and > listening (enabled) mode but the connection is definitely lost. > > thanks for listening. > > > Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth > Dongle (HCI mode) > > > > > The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with > Hotmail. Get busy. > -- > 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 > > -- - Greetings from Rene7705, I have made some free open source webcomponents designed and written by me available through: http://code.google.com/u/rene7705/ , or http://mediabeez.ws (latest dev versions, currently offline) - -- 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
