February 2008 - Wine-Devel - list.winehq.org

Re: appdb feature request: hide the ugly urls

by Remco

> http://appdb.winehq.org/app/command-conquer-3-tiberium-wars/ > doesn't sound too bad, actually. And if somebody types in > an ambiguous URL, like > http://appdb.winehq.org/app/command-conquer > they should get a list of matching apps. So this is kind of > like a search function rather than a unique ID. > The difference being that apps would normally be > displayed at their shortest unique human-readable URL > rather than by ID #. > This may have an obscure but important benefit: I > read on the web somewhere that it boosts search engine rankings. > (Not that I'd know; I'm way away from that part of google.) > - Dan I'm pretty sure that's just because of the related words in the URL. An additional number doesn't hurt ranking. I know a lot of sites use an ID number and a title. The title makes it easy to see what the link points to. That's a usability benefit of itself. I don't think people should start using the URL bar as a search engine. The AppDB has a nice search engine already. And I think searching for literally all URLs is going to put a lot of strain on the server. Remco ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Vitaliy Margolen

Vitaliy wrote: > Vitaliy Margolen wrote: >> Dan Kegel wrote: >>> On Feb 17, 2008 3:19 PM, Remco <remco47(a)yahoo.com> wrote: >>>>> Adobe Premiere is currently at >>>>> http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 >>>>> but it'd be so slick to see instead >>>>> http://appdb.winehq.org/adobe/premiere >>>> That's relatively easy to do with mod_rewrite. But it would have to >>>> be something like: >>>> >>>> http://appdb.winehq.org/app/128/adobe-premiere.html >>>> >>>> All the info is still in the URL (which mod_rewrite can extract), >>>> but it does look less scary. >>> Not quite good enough. People need to be able to guess the >>> URL. We should be able to look up 'adobe-premiere' and get '128'. >>> So maybe http://appdb.winehq.org/app/adobe-premiere.html >>> - Dan >>> >>> >> I don't think that would work all that well. As-is AppDB having all >> sorts of problem with it's search function. You want to break all the >> links as well? Granted having all the links as some ID to some cryptic >> script is even worse. >> >> If you want the link to be a application's name, how about games with >> a huge long name? Like "Command & Conquer 3: Tiberium Wars 1.x". Is >> that easier to enter? I don't think so. >> >> IMHO just fixing the search and getting rid of all those banners in >> the search results would be much more helpful. >> > And while we are on the AppDB topic can someone finally add pages or add > at least one usable threads display mode? Any application with more then > 10 posts is impossible to read! And god forbid a thread having 5 replays > - then it's unusable at all regardless how you looking at it. > > Vitaliy > Now from the right address. And while we are on the AppDB topic can someone finally add pages or add at least one usable threads display mode? Any application with more then 10 posts is impossible to read! And god forbid a thread having 5 replays - then it's unusable at all regardless how you looking at it. Vitaliy

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Dan Kegel

On Feb 17, 2008 4:13 PM, Dan Kegel <dank(a)kegel.com> wrote: >> People need to be able to guess the URL. >> We should be able to look up 'adobe-premiere' and get '128'. >> So maybe http://appdb.winehq.org/app/adobe-premiere.html > > I don't think that would work all that well. > As-is AppDB having all sorts of problem with it's search function. > You want to break all the links as well? No, of course not. All the existing URLs should remain valid. > How about games with a huge long name? > Like "Command & Conquer 3: Tiberium Wars 1.x". http://appdb.winehq.org/app/command-conquer-3-tiberium-wars/ doesn't sound too bad, actually. And if somebody types in an ambiguous URL, like http://appdb.winehq.org/app/command-conquer they should get a list of matching apps. So this is kind of like a search function rather than a unique ID. The difference being that apps would normally be displayed at their shortest unique human-readable URL rather than by ID #. This may have an obscure but important benefit: I read on the web somewhere that it boosts search engine rankings. (Not that I'd know; I'm way away from that part of google.) - Dan

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Vitaliy

Vitaliy Margolen wrote: > Dan Kegel wrote: >> On Feb 17, 2008 3:19 PM, Remco <remco47(a)yahoo.com> wrote: >>>> Adobe Premiere is currently at >>>> http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 >>>> but it'd be so slick to see instead >>>> http://appdb.winehq.org/adobe/premiere >>> That's relatively easy to do with mod_rewrite. But it would have to be something like: >>> >>> http://appdb.winehq.org/app/128/adobe-premiere.html >>> >>> All the info is still in the URL (which mod_rewrite can extract), but it does look less scary. >> Not quite good enough. People need to be able to guess the >> URL. We should be able to look up 'adobe-premiere' and get '128'. >> So maybe http://appdb.winehq.org/app/adobe-premiere.html >> - Dan >> >> > I don't think that would work all that well. As-is AppDB having all sorts of > problem with it's search function. You want to break all the links as well? > Granted having all the links as some ID to some cryptic script is even worse. > > If you want the link to be a application's name, how about games with a huge > long name? Like "Command & Conquer 3: Tiberium Wars 1.x". Is that easier to > enter? I don't think so. > > IMHO just fixing the search and getting rid of all those banners in the > search results would be much more helpful. > And while we are on the AppDB topic can someone finally add pages or add at least one usable threads display mode? Any application with more then 10 posts is impossible to read! And god forbid a thread having 5 replays - then it's unusable at all regardless how you looking at it. Vitaliy

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Vitaliy Margolen

Dan Kegel wrote: > On Feb 17, 2008 3:19 PM, Remco <remco47(a)yahoo.com> wrote: >>> Adobe Premiere is currently at >>> http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 >>> but it'd be so slick to see instead >>> http://appdb.winehq.org/adobe/premiere >> That's relatively easy to do with mod_rewrite. But it would have to be something like: >> >> http://appdb.winehq.org/app/128/adobe-premiere.html >> >> All the info is still in the URL (which mod_rewrite can extract), but it does look less scary. > > Not quite good enough. People need to be able to guess the > URL. We should be able to look up 'adobe-premiere' and get '128'. > So maybe http://appdb.winehq.org/app/adobe-premiere.html > - Dan > > I don't think that would work all that well. As-is AppDB having all sorts of problem with it's search function. You want to break all the links as well? Granted having all the links as some ID to some cryptic script is even worse. If you want the link to be a application's name, how about games with a huge long name? Like "Command & Conquer 3: Tiberium Wars 1.x". Is that easier to enter? I don't think so. IMHO just fixing the search and getting rid of all those banners in the search results would be much more helpful. Vitaliy.

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Dan Kegel

On Feb 17, 2008 3:19 PM, Remco <remco47(a)yahoo.com> wrote: > > Adobe Premiere is currently at > > http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 > > but it'd be so slick to see instead > > http://appdb.winehq.org/adobe/premiere > > That's relatively easy to do with mod_rewrite. But it would have to be something like: > > http://appdb.winehq.org/app/128/adobe-premiere.html > > All the info is still in the URL (which mod_rewrite can extract), but it does look less scary. Not quite good enough. People need to be able to guess the URL. We should be able to look up 'adobe-premiere' and get '128'. So maybe http://appdb.winehq.org/app/adobe-premiere.html - Dan

Feb. 18, 2008

Re: appdb feature request: hide the ugly urls

by Remco

----- Original Message ---- > From: Dan Kegel <dank(a)kegel.com> > To: wine-devel <wine-devel(a)winehq.org> > Sent: Sunday, February 17, 2008 6:55:06 PM > Subject: appdb feature request: hide the ugly urls > > How hard would it be for the appdb to support > more readable URLs for vendors and applications? e.g. > Adobe Premiere is currently at > http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 > but it'd be so slick to see instead > http://appdb.winehq.org/adobe/premiere > > Believe it or not, that little change would make the appdb > less scary for newcomers. > - Dan That's relatively easy to do with mod_rewrite. But it would have to be something like: http://appdb.winehq.org/app/128/adobe-premiere.html All the info is still in the URL (which mod_rewrite can extract), but it does look less scary. Remco ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Feb. 17, 2008

Re: [PATCH] Environment variable to specify X11 window for desktop

by Detlef Riekenberg

On Fr, 2008-02-15 at 15:46 +0000, Robert Shearman wrote: > Timothy Lee wrote: > > The attached patch allows the WINE desktop to be embedded within an > > existing X11 window, and is similar to the windowed mode in WINE. > I'm struggling to imagine a case where the behaviour you've implemented > is useful. With XSCREENSAVER_WINDOW as the Environment Variable: http://wiki.winehq.org/ScreenSavers -- By by ... Detlef

Feb. 17, 2008

Re: Next big app(s) to try?

by denis bonnenfant

Another major application that may be interesting to support is SolidWorks. http://appdb.winehq.org/objectManager.php?sClass=version&iId=8983 Why ? - It's one of the most popular CAD application for mechanical design and engineering, and surely the most used for educationnal purposes. Although the industrial version is quite expensive, thousands of $ or €, it is availiable for free for students in europe, and currently, it is the only app that may prevent them from switching from Windows to Linux. - The Vista version is a pure disaster (or is vista the disaster ?), on a high-end notebook, it runs much slower than on a 4-years old low-end one with Win2K ! I saw many users really disappointed having to switch their brand new notebook back to XP, So there is a real "market" for linux/wine here ! - No MacOs version or alternatives. - No opensource alternatives, and no linux native equivalents too ( Pro/E used to have a linux version, but i have no news about it ) Technically, most of the work seems to be done, i'm regularly testing it against new wine versions, and it mostly works, except 3 blocking bugs that prevent any real use. Unfortunately, it looks like there are no other apps impacted, as I saw no evolution for long months. : + installation just works out of the box, no tricks needed, so testing is really simple, as the downloadable version can be run without registration during one month. + The modeler, the parasolid kernel, works perfectly. Very big assemblies can be opened and modified, and all the functions works, except one. - The most important function, extrude, is crashing, but it is related to the UI only, I guess. unfortunately, I wasn't able to find the problem. http://bugs.winehq.org/show_bug.cgi?id=9545 - OpenGL child windows bug http://bugs.winehq.org/show_bug.cgi?id=2398, or its cousin is still here, it was mostly solved by this patch http://www.winehq.org/pipermail/wine-devel/attachments/20070821/b0f56ecf/wi… , but actual wine version is in regression. - Can't save files, looks like some things are missing in storage implementation http://bugs.winehq.org/show_bug.cgi?id=9396 - Big issues with flicker-free screen redraw, causing visual artifacts and huge bitmaps to be allocated ( surely sync issues, causing0 messages to be passed in bad order, with unallocated values) http://bugs.winehq.org/show_bug.cgi?id=9561

Feb. 17, 2008

programs: add winestartfile for starting files from the unix path (for file managers)

by Vincent Povirk

This is now attempt 4, not that anyone's counting. Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right. This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers: * File managers typically do not set the working directory to the directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it. * File managers naturally use the unix path to start files, and the wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else). * Windows explorer always starts exe files with quotes around the path in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14 -- Vincent Povirk

Feb. 17, 2008