Re: first step of merging the Win installers
"Uwe Stöhr" wrote in message news:4de9a690.2020...@web.de... - I used the custom LaTeX installer page from my installer, only because this is already translated to 22 languages. The page design is a matter of taste, so we can also use yours if you prefer it for a certain reason. This page doesn't fit in the framework of the installer and uses a deprecated NSIS plug-in for the GUI. We now have two different GUI codes in place, one using the modern nsDialogs code and the old code based on INI files. If you don't mind I'll put back the nsDialogs version and we'll just transfer the translations. But LyX is besides Inkscape the only program (of more than 50!) at my PC that don't have its own subfolder. I don't see why we should forbid the users to put it in their custom folder. E.g. thy might have LyX 2.0.1 installed and LyX 1.6.5 too and also LyX 2.1 test releases. Without subfolders you will quickly loose the overview. If you like we can change it that if the user doesn't select a custom folder, we do what you are already doing. These start menu folder selection pages are something from the Windows 95 era. Many programs with only one icon put their icon (correctly!) in the main group. Surely there are other problems that don't follow the Windows GUI guidelines. This doesn't mean we should replicate that. Please see http://msdn.microsoft.com/en-us/library/aa511447.aspx Specifically: "Eliminate unnecessary folders by putting programs at the top level or in a single product folder. Generally, your program should have a single shortcut on the Start menu." "Create a product folder only if your product is a collection of individual programs (three or more), and users think of your product in terms of that collection." I'll remove it then. OK To the topic: When I run the installer from within a user account, LyX is also only started with user privileges. So I don't see the problematic. But have you tested my version? This ioption is by default unchecked so it shouldn't harm. That's probably because you're using Windows XP. If you use a more recent Windows version with UAC and install LyX for all users which requires administrator privileges, LyX itself will also run with administrator privileges and will use the administrator directories. When LyX it started later the normal way no administrator privileges are required and the user directories are used. This means all preferences etc. are lost after running LyX the first time. Broken features should not be included IMO, even if unchecked by default. I don't understand. The ides is to give our colleagues the option to build the bundle and small installer versions as easy as possible. So it should be one script that builds both installers at once. For us developers it should be good to have a script where we can select only to build e.g. the bundle installer. How can I do this with the existing script in the NSIS GUI? I've put the shared code in the common file. But I can use IM, GS and also Python here without problems also without admin privileges. So why do we need special versions? ImageMagick for example can only find Ghostscript through a HKLM registry key which required administrator privileges for installation. Sure. As i told, this version is a proposal and not ready. I merged your version with my routines and did not yet sanitized this ones. There are other superfluous routines there as well that I will remove bit by bit. Yea the detection of external programs became really messy now. We should merge and clean this up. What I don't like about this MiKTeX detection code is the lack of forward compatibility (e.g. MiKTeX 2.10 won't work) and the code duplication for each version. What it wrong with the generic code that I used? Not in my opinion because: When I'm already a LyX user I have MiKTeX already installed and thus don't need it. I only need it as new user and in this case the problem appears that i described. The bundle installer therefore only makes sense with MiKTeX included and is only to be used for new installations as you then need MiKTeX anyway. I don't understand. The bundled version always included MiKTeX. I'm talking about having the option to download MiKTeX in the standard installer. Joost
Re: first step of merging the Win installers
Hi Uwe, Below are my comments/concerns. I guess in the future it's better to have a little discussion on the devel list first so things don't have to be reverted. "Uwe Stöhr" wrote in message news:4dd9dfbf.2080...@web.de... > - you installed LyX's sty-files always to MiKTeX's user folder. But when LyX is installed for all > users, we need to install them to MiKTeX's main folder to be available for > all users What if the user is not the administrator and only installs LyX for his/her own user account? AFAIK this was the reason why I changed the implementation. > - I used the custom LaTeX installer page from my installer, only because > this is already translated to 22 languages. The page design is a matter of > taste, so we can also use yours if you prefer it for a certain reason. The custom page system was a generic one supporting additional applications if needed in the future. I think it's better to keep that. > - there is now an installer page where you can select LyX's start menu > folder. This was once requested by users. I don't agree with this. There's no reason to have a subfolder in the start menu because we only have one shortcut. It should be in the main start menu according to the Microsoft UI guidelines. > - there is now an installer page where you can select the components to > install like JabRef and GSview, if there should be a desktop icon or not > and if the .lyx file extension should be linked to the installed LyX > version. I'm not sure about GSview. It's commercial software with a nag screen. I think it should be removed. > - the last installer page has now an option to start LyX after the > installation. The option is by default disabled, but this feature is kind > of standard (users expect this, especially new ones). This was removed on purpose because LyX will run with the wrong user account since the installer has elevated privileges. So any preferences that are changed etc. will not be preserved. Please remove it until a proper solution is implemented. > - register also *.lyx14 and *.lyx13 to LyX if the user agreed to link > *.lyx to the new LyX version. > > - created 2 different nsi-files. This way you can simply execute the > lyx-bundle.nsi file and get a ready to use bundle installer. (No need to > edit an NSIS file.) There's no reason to duplicate code. Defines can be set in the NSIS GUI, but if you prefer a seperate file do something like: !define SETUPTYPE_BUNDLE !incluce lyx.nsi > (-you can ignore my path changes insettings.nsh, I'm to lazy to remove > them (they went in accidentally)) Please do revert. The paths no longer match INSTALL.Win32 now. > > - why do you use a file list for things like the fonts? They are all in LyX's Resources folder like > the layout files and scripts. Moreover, you missed 2 fonts in your list. > Also for python and Ghostscript there is no list necessary because we can > file the whole folder recursively. Yea those lists I removed already. I think I forgot to commit. > - why do you use special versions of Python and Ghostscript? This makes it > hard for other to build the installer and I don't see why this is > necessary. It is also harder to keep them up to date. I built an installer > where I used the official versions of the latest IM, Python 2.7.1 and GS > 9.0.2. They work fine here on my two test PCs - one with GS and Python > pre-installed, one without them. They are special portable versions. They don't work by default without administrator privileges. Can you remove the code for detecting external Ghostscript/Python etc.? I really want to keep bundling a tested combination of the external tools which also support normal user accounts. > - you don't have the LyXLauncher in your dependency package. Can you > please add it. That's because it's gone. There's no need for LyXLauncher anymore. LyX is now a real Windows GUI application. Please set APP_RUN back to LyX.exe. > Some generalities: > > - the idea is to provide an installer that can be used by every developer > if he has NSIS installed. He can then call the lyx.nsi file and get a > ready to use installer. Everything should be possible withing the > checked-out SVN folders. I therefore want to put your dependency package > also to SVN. The dependency package is downloaded automatically by CMake. > - MiKTeX should not be downloaded. Bundling it has the advantage that the > user can download one installer I think it's a good feature to offer a download option in the standard installer. > - decrease the installer size by not shipping every exotic spell checker > language file. I plan to ship only the English files by default. Others > can be installed from the Web. A normal user only needs 1 language (and > not 113 as we currently ship) and downloading/installing it doesn't > require a broadband connection. I'm OK with that if we should keep the current UI but download the dictionaries instead. > The install
Re: still not possible to compile LyX 2.0.x with CMake
"Peter Kümmel" wrote in message news:4dd58dae.5040...@gmx.net... > Yes, I see. Only when the entry is also set in the cache the gui shows the > correct value. > The problem was, when a option is implicitly set, like HUNSPELL when > INSTALL is set, > HUNSPELL would be still ON even when INSTALL is not set in the next cmake > run. This > makes it harder to switch between several configurations without cleaning > the build > folder in the meantime. But having wrong values in the gui is maybe a > bigger problem. Yes setting the options also in the GUI is the best option I think. Perhaps LYX_INSTALL could be renamed to clarify what it's doing. Joost
Re: still not possible to compile LyX 2.0.x with CMake
"Uwe Stöhr" wrote in message news:4dd51e0b.3010...@web.de... > It is the same, but doesn't work, neither in trunk nor branch. I have to > set it manually. > Perhaps because it is only set on Win32, but I am on Win64. IIRC it does work but it doesn't show in the CMake UI. Joost
Re: [HELP] Windows 7, 64 bit Bug
"Vincent van Ravesteijn" wrote in message news:4dd16a18.1080...@lyx.org... > The reason was that the installer configured LyX using the > preferences of LyX 1.6. In particular this meant that in Tools > ->Preferences->Path, there was the path to > C:\Program Files\LyX16\python which didn't exist anymore. I noticed the prefs2prefs script. Does it try to import the PATH from the LyX 1.6 preferences? If this is the case that's definately a bug, because the preferences would override the value in lyxrc.dist. Joost
Re: [HELP] Windows 7, 64 bit Bug
"Vincent van Ravesteijn" wrote in message news:4dd16a18.1080...@lyx.org... > The reason was that the installer configured LyX using the > preferences of LyX 1.6. In particular this meant that in Tools > ->Preferences->Path, there was the path to > C:\Program Files\LyX16\python which didn't exist anymore. > > Another possibility is that this path points to > "C:\Program Files\LyX20\..." instead of > "C:\Program Files (x86)\LyX20\..". > > Can the bug reporter check this ? Are you sure about this? LyX 2.0 has it's own user directory (LyX20) with a separate preferences file. Joost
Re: How to compile LyX with MSVC 2010?
"Uwe Stöhr" wrote in message news:4dcebf92.8010...@web.de... > I'm using Joost#s dependency package for MSVC 2010. > > Any ideas? Did you follow the instructions in INSTALL.Win32? Joost
Re: Directory cleanup
"Jean-Marc Lasgouttes" wrote in message news:4dcd44ce.6090...@lyx.org... > I'd have to understand what the actual patch is. I did not find it at > first glance in the zip file. The subdirectories in the zip file contain the patches. There are quite a lot of them. Joost
Re: Directory cleanup
"Abdelrazak Younes" wrote in message news:4dcb8b0d.6090...@lyx.org... > AFAIK Joost maintains such a dll. Joost could you please update the intl > directory with whatever fixes you have? > AFAIK2 the gettext developpers have dropped msvc support a long time ago. Yes there's no MSVC support maintained by the gettext developers. MSVC patches and a CMake build system are available at ftp://ftp.devel.lyx.org/pub/contrib/windows/src/ I didn't write this code myself. There used to be SourceForge project "cgettext" maintaining this, but for unknown reasons it's entirely gone now. I had a copy of the gettext 0.17 files around which is what we're using now on Windows. Joost
Re: Directory cleanup
> On 05/12/2011 10:15 AM, Jean-Marc Lasgouttes wrote: > Could we in general depend on gnome dependencies instead of ours? AFAIK those binaries are all based on MinGW. We use MSVC. Joost
Re: merging status of the Windows installer for LyX 2.0
"Peter Kümmel" wrote in message news:4dcb63e3.6070...@gmx.net... Joost, how do you compile libintl? With Mingw or does it work with msvc? Couldn't we use the libintl shipped with lyx? libintl is also compiled with MSVC 2010. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dcb36a7.4090...@web.de... Why is MSVC 2010 required? What feature do we use that is not in MSVC 2008? However, I can successfully compile LyX with the linked hunspell. Hunspell probably works because it's a C library, although now you need both the 2008 and 2010 runtimes. C++ libraries will crash. I'd definitely recommend you to upgrade to MSVC 2010 so we can both compile the official releases. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dcb0acc.20...@web.de... Why is MSVC 2010 required? What feature do we use that is not in MSVC 2008? If possible I don't want to switch to MSVC 2010 because I tested it last year and it was unstable. It also requires much more disk space (which I currently don't have). The dependencies are linked to the MSVC 2010 runtimes. You cannot mix different runtime versions. I'm using MSVC 2010 SP1 and never had any stability issues. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dcb1094.2020...@web.de... For multi-user installations it's also impossible to download them directly to the program files because of the need for administrator privileges. Sure, a normal user cannot set up things for other users on the PC. That is for a good reason. So if you want to install LyX for all users you need to have admin priviledges - this is already the case with your installer. Even if you got administrator privileges, you cannot download files to program files. So first you need to save them somewhere else and them move the files to the LyX directory. Creating separate installers for each language (as we did for Aspell) is not an option because of the huge maintenance burden. That is not my plan. The installer will download additional dictionaries by simply downloading them from the Internet and copy it to the location, where the English version is (that will always be included in the installer). So you want to show a list of all available languages and allow the user to select which ones to download? Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc9f19f.3030...@web.de... Btw., can you please send me the hunspell.lib, iconv.lib and intl.lib files? Currently I cannot compile LyX against hunspell for that reason and i can also not use the new versions of intl and iconv you ship with your installer. If possible, can you update your MSVC dependency package you once kindly provided and put it on ftp.lyx.org? All dependencies are available at ftp.devel.lyx.org/pub/contrib/windows (MSVC 2010 is required). The best way is to follow the instructions in INSTALL.Win32. CMake will download the dependencies automatically. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc9f4fd.9020...@web.de... So - maybe full offline installation wasn't all that convenient, but it was at least possible - please don't cut off this way. We won't cut that of. But note, to have a fully functional LaTeX installation, you at least once need to open an Internet connection and reconfigure LyX to get the LaTeX-packages LyX needs. There is no other way. If we remove the dictionaries and thesauri from the LyX installer, it will require quite some manual work to install them. There are different files for the dictionaries and thesaurus lists that need to go in different directories. For multi-user installations it's also impossible to download them directly to the program files because of the need for administrator privileges. Creating separate installers for each language (as we did for Aspell) is not an option because of the huge maintenance burden. Unless a more user friendly solution is developed, I'm not sure it's a good idea to remove the files from the installer. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc9f3f7.90...@web.de... OK, there was indeed a problem with my MiKTeX installation residues in the registry. now the installation runs through as expected, but there are thing we should improve: a. When LyX is installed together with MiKTeX we need to set an installation location and hide MiKTeX's window that asks for every LaTeX-package. New users don't understand what a LaTeX-package is - they will learn it in the LyX tutorial but thus after the installation. I therefore set in my installer MiKTeX without showing the asking windows and just start installing the packages. (Once the MiKTeX developer especially built in the feature for LyX.) That's fine. I think this should only be set when MiKTeX is installed together with LyX. b. the installer has a button "Details", but this button should be pressed by default when MiKTeX is installed together with LyX. This only affects new users and they might not expect that the installation process can take many minutes. I therefore also state this in my installer because I once got several complaints. There's also the message above the progress bar indicating the MiKTeX configuration takes a while. Do you think it's necessary to show all the technical details of configure.py which the user probably won't understand? Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc9150a.9060...@web.de... Am 10.05.2011 02:08, schrieb Uwe Stöhr: Seems to be a problem of the MiKTeX repositories: LyX's first run of configure.py runs through without installing any LaTeX-package. That's why I couldn't see in this case no feedback from the installer. I'll investigate further. Yes I noticed this too now when doing a fresh installation on XP 64-bit. Let me know if you can find out what's going on with MiKTeX here. So for now the ToDo-list for the merged installer is: 1. check if Inkscape is already installed and use it for SVG images (I can no longer provide/maintain support for checking for Adobe Illustrator) 2. implement to ask to update MiKTeX at the end of installation process 3. option in the uninstaller not to uninstall the metafile2eps printer 4. include JabRef to the bundle installer version (there will be an option not to install it as in my installer) 5. option to start LyX after installing it (which will be unchecked by default) 6. sanitize the hunspell dictionaries installation (to be discussed further how to do this) 7. ask on the users list for the GUI language setting issue So not much to do for now. Joost, can I start to implement point 1 and 2? Yes please go ahead! 1 and 2 seem simple 3 could be automatic by detecting a different version being installed 4 probably reuse the "external" app code in the installer 5 requires a separate thread without UAC because of the issues discussed earlier Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc9150a.9060...@web.de... I tried to resolve the known issues in the new 2.0 version of the Metafile 2 EPS converter. Joost fixed this yesterday. I made some more improvements to metafile2eps today. I'll prepare updated installers. 7. It is not possible to select the LyX GUI-language in the installer. My installer provides this feature, because it was once often requested. I didn't noticed yet that in cases like this, the installer language will also be German, so setting the GUI language in the installer is no advantage. I think to remember that I introduced this feature for an installer of LyX 1.4.x when setting the GUI language via the preferences didn't work on LyX for Windows. So I don't know what is better, to implement the GUI language setting in the installer or not - I'll ask on the lyx-users list. Yes there was a bug in gettext which is fixed now. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc7ddbe.2020...@web.de... 5. The latest version of the metafile2eps printer gives an error message when it is first used: When I compile a LyX file containing a wmf-image, I get the error message that the printer could not be successfully be initialized. For all further uses of the printer, I don't get this error. However, the WMF-image is still rotated by 90° in the output, so that WMF-images can still not be used for real-life documents. I can send you a LyX test file showing the problematic. Actually I think the file was just stored in the file cache, which is why you don't see the error the second time. I can reproduce this now on XP 64-bit. Probably a different version of the Postscript driver. I'll look into this. Joost
Re: merging status of the Windows installer for LyX 2.0
"Jim Oldfield" wrote in message news:868476.20267...@web29206.mail.ird.yahoo.com... > Personally, am I happy to sacrifice 40MB of disk space if it means that uninstalling other programs doesn't suddenly stop LyX from working. This is the "Windows way" sadly - since there is no package manager, things end up duplicated (e.g. your list doesn't include detection of QT .dlls). That also a good point. I agree the "Windows way" is not ideal in terms of disk space, but it's the best option we have. I have a related question, which came up on lyx-users recently. What happens if you install two copies of LyX (e.g. 2.0.x and 1.6.x)? Presumably the second installation doesn't "harm" the metafile2eps printer, but when one of them is uninstalled, is the printer gone forever? Yes the uninstaller would remove the printer. We should probably detect if other LyX version are still installed. Presumably when LyX is installed for one user in their profile folder (rather than for all users in program files) the registry key is in a different location too. If so, this feature should only be added if this is taken into account. I have mixed feelings about the "delete user settings" option existing at all. In the situation I discussed in 10, this option has no effect, and worse the user has no way of knowing this. So I think it should only be present if LyX was installed in a user profile folder (not the program files directory). Yes, you're right. If the installer is run from the administrator account, it won't delete the user preferences. Perhaps that's why Uwe had this issue. I don't think there's a way around this. An even better idea, if it is possible, is to capture the stdout/stderr of this and redirect it to a list box in the installer, possibly hidden behind a "more details" button. Until the "more details" button is clicked, a simple warning about the length of the process could be shown. That's exactly what the installer is doing now. Joost
Re: merging status of the Windows installer for LyX 2.0
"Uwe Stöhr" wrote in message news:4dc7ddbe.2020...@web.de... the last days I tested your new installer. You have done a good job!: the installer code is much more understandable and contains more comments to be able to understand the code. Thanks. As we once agreed, we should only provide ONE installer for LyX on Windows. I'm a bit sad that you never contacted me to work with you on the new installer. The end of 2010 I had time to work on this. However, to finish the merging, the following things must/should be fixed: Yea I didn't have time in 2010, and after that you went to South America. But let's now work together to put in the additional features. Since we're having one official installer, we should probably keep the discussion on the devel list to make sure other people agree as well. 1. the installer doesn't recognize if Ghostscript is already installed 2. the installer doesn't recognize if Python is already installed 3. the installer doesn't recognize if Imagemagick is already installed For computers where these are installed, we unnecessarily take 42 MB of disk space. In my opinion it's better to bundle a tested combination of these tools with LyX. There's no way to test all possible combinations of Python/ImageMagick/Ghostscript versions and to ensure they work well together and with LyX. Also note that I don't just install the standard binaries. They are customized portable version which don't need administrator privileges. 4. the installer doesn't recognize if Inkscape is already installed Because of this, SVG images look broken within LyX. Good suggestion. 5. The latest version of the metafile2eps printer gives an error message when it is first used: When I compile a LyX file containing a wmf-image, I get the error message that the printer could not be successfully be initialized. For all further uses of the printer, I don't get this error. However, the WMF-image is still rotated by 90° in the output, so that WMF-images can still not be used for real-life documents. I can send you a LyX test file showing the problematic. I tried to resolve the known issues in the new 2.0 version of the Metafile 2 EPS converter. Apparently there's still a compatibility issue with some Windows versions. Because of the use of the Postscript printer drivers, compatibility is always a difficult thing with this tool. What Windows version are you using? 6. When LyX is uninstalled, the registry key HKCU\Software\LyX\lyx20 is not deleted. This causes problems when LyX is reinstalled, because there the toolbar settings etc. are stored. That's a bug. Should be an easy fix. 7. It is not possible to select the LyX GUI-language in the installer. My installer provides this feature, because it was once often requested. This setting is also in the LyX preferences. We can duplicate it in the installer if you want. My main concern was having to maintain an additional list of supported languages. 8. The installer doesn't ask the user to update MiKTeX. This is an important feature, because many of the problems discussed at lyx-users mailing list are the consequence of a bug in LaTeX-packages or MiKTeX. By asking to update MiKTeX, we assure that MiKTeX is updated from time t tome. Since I implemented this in my installer, the number of bug reports/questions at the mailing lists could be reduced. Sure, should be easy to do. Perhaps a checkbox on the finish page? 9. The installer doesn't allow to decide if the new LyX version should be associated with the *.lyx file extension. This is a useful feature if conservative users still want to open *.lyx-files with LyX 1.6.10 and not 2.0. (for example if they are working on important LyX documents that they begun with LyX 1.6.x. Perhaps this could be added to LyX itself? So people can change it afterwards without having to reinstall? 10. The last installer page should have an option to start LyX after installing it, as in my installer. This behaviour is more or less a standard and many people expect that the program is opened after installing. This is because LyX will likely be run with the wrong user account, and therefore the preferences etc. will be lost afterwards. It could be fixed with two installer processes with and without UAC. Other things just had priority. 11. When installing LyX the first time, and therefore also MiKTeX is installed the first time, the configure.py file should be run in a console window. This is very important because the first installation will install more than 50 LaTeX-packages and take approximately half an hour. In the console window the user can see that there is some progress. Without this information, many users will kill the install process because they think it hung up. What exactly do you mean? The installers already prints a message saying this should take a long time. And there's a "Show details" button. 12. We should not ship all hunspell dictiona
Re: Dictionaries location for LyX on Linux
At the time I stepped in and added this dataDirectory relative to lyx's system and user directories there was only one path for hunspell available: the one in preferences. This one now is the first one visited. The idea to add the other paths was to incorporate some dictionary download into LyX - but it didn't happen - I couldn't afford the development of such a feature. The files to download should be placed in the user directory of LyX. The package maintainers can put a default in lyxrc.dist, right? Joost
Re: Trunk is completely frozen for any commits [unfrozen]
"Pavel Sanda" wrote in message news:20110505061312.ga15...@atrey.karlin.mff.cuni.cz... Joost do you have time to fix (in another words should i wait with announce for the new version)? I was just able to reproduce the problem. Compiling new installers now. Joost
Re: Pdf problem
"Enrico Forestieri" wrote in message news:20110413211218.ga8...@sirio.sssup.it... My wild guess is that that pdfview thingie is using DDE commands for opening pdf files. As Adobe changed the servername in Reader X, it does not work anymore. LyX is not the only software which was broken. Have a look here: http://forums.adobe.com/message/3562383 That's correct. However, I updated pdfview to support Reader X and it's working fine for me. I'll try to create a debug version of pdfview that outputs some more info. Joost
Re: LyX 2.0 RC2 for Windows
"Diego Queiroz" wrote in message news:BANLkTim6fQ-7u+04_zMnOf5Zb2vh1=e...@mail.gmail.com... Here is the screenshot of C:\Program Files\Adobe\Reader 10.0\Reader\AcroRd32.exe. You're talking about Adobe Acrobat, right? Not Adobe Reader? If yes please also send the info of Acrobat.exe instead of AcroRd32.exe. Joost
Re: LyX 2.0 RC2 for Windows
"Diego Queiroz" wrote in message news:banlktinv39cbo6klvortkyfodtymtka...@mail.gmail.com... I've found this bug when I installed Adobe Acrobat X also (when you click to view PDF, the Adobe Acrobat app starts as well but the file is not oppened), but it is not exactly related with Adobe Acrobat installation. Could you locate Acrobat.exe on your system, right click, open Properties and click the Details tab? Please send me a screenshot of the info in that list. Thanks, Joost
Re: "Package" not initialized under Win32 with CMake
wrote in message news:65388B121D284A0088A95CB71C14A75F@venomobile... OK, sorry :P I was using Qt compiled with MSVC2008 and using MSVC2008. Are you aware that the package of pre-compiled dependencies requires MSVC2010? Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Vincent van Ravesteijn" wrote in message news:4d8cd11d.8000...@lyx.org... Why is this post-2.0 stuff. This is not so difficult ? I think Jurgen's concern is the RC status. As a final suggestion for 2.0: Maybe the UI file could be linked to an icon directory (instead of the preferences which are being developed now) and we could add an "experimental" UI file linked to the new icons and toolbar. This way it will be totally separate from the old default UI, and maybe allow for some discussion regarding a new default UI in the future. What are the issues that are still left then ? There aren't real issues. IMO it would already be a much better UI as compared to 1.6. However if the complete UI changes cannot be incorporated because of the RC status, I would suggest to keep the new UI separate instead of enabling only parts of it. Then hopefully in 2.1 it can be enabled by default. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Jürgen Spitzmüller" wrote in message news:201103251812.22547.sp...@lyx.org... The whole thing is not for 2.0. Bad luck. People had two years time to come up with UI proposals. Perhaps it's better to postpone all the UI stuff to a future release. It seems like discussions with a bit of controversy (e.g. UI) get stalled during development because there's no "manager" to take the final decision. Then at the last moment everyone realizes something needs to happen, and others object because of the deadlines. As a final suggestion for 2.0: Maybe the UI file could be linked to an icon directory (instead of the preferences which are being developed now) and we could add an "experimental" UI file linked to the new icons and toolbar. This way it will be totally separate from the old default UI, and maybe allow for some discussion regarding a new default UI in the future. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Jürgen Spitzmüller" wrote in message news:201103251748.53062.sp...@lyx.org... Now having the same item twice (even if one toolbar can be disabled) is *really* bad UI design. A better idea would be to introduce OptItem for the toolbar to let the master-buffer-* items disappear if the document in question is no child. It might not be ideal, but there are more of such cases in the current toolbars for the same reason. I object (once more). A proper reorganization of the toolbar needs more time and probably some more changes (such as the OptItem stuff outlined above). The alternative is to keep the current ad-hoc design with e.g. thesaurus next to paragraphs settings. New code will allow for more improvements, however that's definitely is not for 2.0. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Enrico Forestieri" wrote in message news:20110325143448.ge29...@sirio.sssup.it... I don't agree. As you can see, additional icon sets may simply subsitute some icons. If an icon is missing, the one from the default set will be used. So, there's no maintaining burden as only those icons that don't fit well a given set need to be added. Moreover, it would not be fair with whom spent a good deal of time on the icons. We should also consider tutorials, manuals etc. Things will get much more confusing if different installations have different icons. I spent a lot of time on the oxygen icons, but I'd definitely prefer to have the liber icons as new default rather than to add more options because we couldn't reach consensus. The time spent on the oxygen icons wasn't wasted even if "liber" becomes the new set. It did trigger the discussion which resulted in the UI improvements in 2.0. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Enrico Forestieri" wrote in message news:20110325162427.gn29...@sirio.sssup.it... Hmmm... the artifacts are now gone, but the toolbars are still unrensposive. No problems here. Did you try a clean user directory? Perhaps there's still some session info left. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Enrico Forestieri" wrote in message news:20110325161616.gm29...@sirio.sssup.it... Yep, that did the trick. However, it is going to surprise many people. BTW, why the "View" button appears twice? Even if it is in two different toolbars, they are the default ones. Because many users don't need the advanced view/update features. With the "View" button on the standard toolbar, it's no longer needed to have a large additional toolbar. It's indeed a good idea to have a look at this session info bug, but the toolbar should go in now because of the freeze. Can you undo the revert? Joost
Re: Error in clean_dvi.py in Lyx 2.0 RC1
"Ola Ringdahl" wrote in message news:4d8c95d6.7080...@cs.umu.se... There seems to be an error in clean_dvi.py in the windows version of Lyx 2.0 RC1. When trying to produce a dvi output (ctrl-D, dvipdfm or ps2pdf) Lyx gives an error (see the atached screenshot). Replacing clean_dvi.py with the one from Lyx 1.6.9 solved the problem. You're right. I'll fix that. Joost
Re: r38037 - lyx-devel/trunk/lib/ui
"Enrico Forestieri" wrote in message news:20110325142851.gd29...@sirio.sssup.it... On Fri, Mar 25, 2011 at 01:17:19PM +0100, Joost Verburg wrote: Why did you revert this? What was broken? See attached screen shot. Moreover, the toolbars where unrensposive and only through the main menu I could open a new file. Please try to clear the session / registry info. The toolbar is fine, LyX is probably just trying to apply the stored position of the old toolbars. Joost
Re: Final round for UI changes
"Enrico Forestieri" wrote in message news:20110325144230.gj29...@sirio.sssup.it... Because it was broken. Apart from artifacts in the upper left corner, after starting LyX with no document open, the toolbars where not responding when clicked. That's probably because your session file contained positions etc. of the old toolbar. The toolbar works fine. Joost
Re: Final round for UI changes
"Enrico Forestieri" wrote in message news:20110324030315.ga29...@sirio.sssup.it... Here is another possible set of icons to be considered. I just noticed the last minute work on the new "liber" icon set. Perhaps we should delete the "oxygen" and "old" sets so only one style of icons has to be maintained? Joost
Re: Final round for UI changes
"Edwin Leuven" wrote in message news:AANLkTi=+t2HRjX4oZCoozDFo760_Mo0uVPZ4j5C_x=k...@mail.gmail.com... i guess only the new toolbar layout is left... Yes. I did upload the new toolbar (with optional "classic" toolbars in addition), but Enrico reverted this. I'm not sure why. Joost
Re: r38036 - lyx-devel/trunk/development/cmake
"Kornel" wrote in message
news:201103250733.23097.kor...@lyx.org...
Why everything instead of adding only *.R?
lyx_install(${TOP_SRC_DIR}/lib lyx2lyx *.py .)
+lyx_install(${TOP_SRC_DIR}/lib scripts *.R .)
Kornel
Yes that's also fine.
Joost
Re: Conversion Error
"Richard Heck" wrote in message news:4d87a8cf.2070...@comcast.net... Can you please repeat for me exactly what the error is and how I can reproduce it? There was a bug along these lines a while ago. I'm not sure why it has resurfaced. 1) Create any module with an inset, e.g.: InsetLayout CharStyle:Drop_Cap LyxType charstyle LatexType Command LatexName dropcap LabelString dropcap Font FamilyRoman Shape SmallCaps EndFont End 2) Add the module and use the inset in the document 3) Go to document settings, change something and click OK 4) You'll see a bunch of "class conversion errors" like "Flex inset Code is undefined because of class conversion from ... to ..." 5) Export to PDF. Now the errors which were previously in the log dialog show up again as "export errors". So there are two bugs here: * The class conversion errors shouldn't happen * The log isn't being cleared and previous errors therefore prevent PDF export etc. Joost
Re: Conversion Error
"Liviu Andronic" wrote in message news:AANLkTinV1z9NZR2pe_GXk08aB5vF2+gMPG=owm7fx...@mail.gmail.com... Wild guess: is it possible that after a class change the modules previously loaded get unloaded? Have you tried removing and re-inserting all the used modules? It also happens without changing the class. Joost
Re: Conversion Error
"Rob Oakes" wrote in message news:000b01cbe7fa$547ab800$fd702800$@oak-tree.us... Any idea as to what might be causing them? The export errors bug is fairly new. I thought that it might be specific to Mac OS X, but after updating the SVN version on my Linux box this morning, I'm getting them there as well. It's definitely related to the modules. After changing any document setting, a class conversion is performed even though the class didn't change . That conversion apparently fails to take into account the modules. The second problem is the fact that those errors remain in memory and prevent LaTeX export, now showing up as export errors. Joost
Re: Conversion Error
"Rob Oakes" wrote in message news:c27fccf8-7391-4fe2-87f0-ab02ae46c...@oak-tree.us... Undefined Flex inset Also, after going to the document settings I'm no longer able to view the PDF output. These "class switch errors" come back as "export errors", although they are unrelated to LaTeX. Looks like the log window isn't cleared correctly. Joost
Re: Conversion Error
"Rob Oakes" wrote in message news:c27fccf8-7391-4fe2-87f0-ab02ae46c...@oak-tree.us... Since yesterday, I've run into a new problem as well. I will occasionally get another error which says: Undefined Flex inset The description says: "Flex inset Code is undefined because of class conversion from ... to ..." I'm getting the same error whenever changing something in the document settings. This didn't happen in 1.6. Joost
Re: ANNOUNCE: Windows installer for RC1
"Abdelrazak Younes" wrote in message news:4d87341c.5050...@lyx.org... I am not sure this is wise... might even be a good reason to step back to MSVC2008... at least until Qt switches to MSVC2010... But you are the one to decide. Windows 2000 is 12 years old and no longer receives security fixes. Therefore it's hardly used anymore. I'm maintaining a dozen of dependencies and simply don't have the time to support different compilers. Last year I decided to use MSVC 2010 for the new dependency platform in order to be future proof. Spending months to develop new dependency packages which only support an old compiler just didn't make sense to me. Joost
Re: ANNOUNCE: Windows installer for RC1
"Michal" wrote in message news:20110321074737.2ec3@ms-dual... This might also be somehow related to http://www.mail-archive.com/lyx-users@lists.lyx.org/msg85707.html, though I haven't checked LyX 1.6.9 at all. No, LyX 1.6.9 contains the right file. Windows 2000 is no longer supported by the current Microsoft compilers. Joost
Re: ANNOUNCE: Windows installer for RC1
"Vincent van Ravesteijn" wrote in message news:AANLkTi=91sdj0xspvtseutxq5iddc7hivpmw8ygta...@mail.gmail.com... Iconv.dll depends on msvcr90.dll. An old file somehow ended up in the dependency package. I'll update the installers. Joost
Re: CMake issues
"Vincent van Ravesteijn" wrote in message news:4d863447.70...@lyx.org... The problem is that cyggomp-1.dll is missing. I guess this should be included in the msvc10-deps package. Thanks. Will fix that. Joost
Re: Final round for UI changes (was: Towards rc2)
"Edwin Leuven" wrote in message news:aanlktikf5+pazt7uj+cga+wkt1kj+3hpsc_xfpkkg...@mail.gmail.com... imo, 4 good reasons to go for it now I agree. Updating the icons and toolbar together makes much more sense. If we put it in now, there's enough time left for fine tuning. Joost
Re: LyX 2.0.0 release candidate 1 - (Non official Win32 binaries)
"Pavel Sanda" wrote in message news:20110316165005.go25...@atrey.karlin.mff.cuni.cz... rc1 installer is announced by Joost in one week, so for this moment things are ok, but it would be good if you can try to reproduce the buidling process and let us know whether the instructions can be followed by somebody else. The Windows installer for RC1 will be available later today. Joost
Re: Final round for UI changes (was: Towards rc2)
"Pavel Sanda" wrote in message news:20110319155427.gd25...@atrey.karlin.mff.cuni.cz... ok, so at this moment we know the new default is going to be oxygen. Should I upload the new icons? Joost
Re: Release 2
"Pavel Sanda" wrote in message news:20110314000522.gl25...@atrey.karlin.mff.cuni.cz... Michal wrote: While I still don't know why msvc2008 is no longer recommended, it i think the reason is that Joost (who was recently working on new installer) is simply using and testing with 2010. All dependencies are linked against the MSVC 2010 runtime and won't work in combination with MSVC 2008. You'll get crashes and other unexpected issues. An official installer for 2.0 RC1 will be available in about one week. Joost
Re: Towards rc1 (status update #3)
"Pavel Sanda" wrote in message news:20110302005838.gj30...@atrey.karlin.mff.cuni.cz... Rob Oakes wrote: but did we ever come to a consensus as to which icons we might want to use? no, i only remember libreoffice style gained most votes... Some people preferred Oxygen style icons and others preferred LibreOffice style. I would be fine with any new and consistent set. Unless someone is working on a another icon set, I think for 2.0 the decision is whether to do nothing or to introduce the new Oxygen style set. I 'd of course vote for the latter. I also think a few icons should definitely be moved to a more logical position (thesaurus for example). Joost
Crash on Windows when searching citation
Hi all, On Windows with current trunk I'm getting a crash when clicking the Search button in the Citation dialog. Not sure what's going on. GuiApplication::notify reports a "regular expression error" which is strange because the error occurs in the mouse event handling. Any ideas? msvcr100d.dll!_NMSG_WRITE(int rterrnum) Line 217 C msvcr100d.dll!abort() Line 61 + 0x7 bytes C LyX.exe!lyx::lyx_exit(int exit_code) Line 236 + 0x8 bytes C++ LyX.exe!lyx::frontend::GuiApplication::notify(QObject * receiver, QEvent * event) Line 2187 + 0x7 bytes C++ QtCored4.dll!QCoreApplication::notifyInternal(QObject * receiver, QEvent * event) Line 732 + 0x15 bytes C++ QtCored4.dll!QCoreApplication::sendSpontaneousEvent(QObject * receiver, QEvent * event) Line 218 + 0x38 bytes C++ QtGuid4.dll!QApplicationPrivate::sendMouseEvent(QWidget * receiver, QMouseEvent * event, QWidget * alienWidget, QWidget * nativeWidget, QWidget * * buttonDown, QPointer & lastMouseReceiver, bool spontaneous) Line 3103 + 0xe bytes C++ QtGuid4.dll!QETWidget::translateMouseEvent(const tagMSG & msg) Line 3321 + 0x2a bytes C++ QtGuid4.dll!QtWndProc(HWND__ * hwnd, unsigned int message, unsigned int wParam, long lParam) Line 1659 + 0xc bytes C++ user32.dll!771e62fa() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!771e6d3a() user32.dll!771e6ce9() user32.dll!771e77c4() user32.dll!771e788a() QtCored4.dll!QEventDispatcherWin32::processEvents(QFlagsQEventLoop::ProcessEventsFlag> flags) Line 807 C++ QtGuid4.dll!QGuiEventDispatcherWin32::processEvents(QFlagsQEventLoop::ProcessEventsFlag> flags) Line 1170 + 0x15 bytes C++ QtCored4.dll!QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag> flags) Line 150 C++ QtCored4.dll!QEventLoop::exec(QFlags flags) Line 201 + 0x2d bytes C++ QtCored4.dll!QCoreApplication::exec() Line 1009 + 0x15 bytes C++ QtGuid4.dll!QApplication::exec() Line 3720 C++ LyX.exe!lyx::frontend::GuiApplication::exec() Line 1935 + 0x8 bytes C++ LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Line 398 + 0x28 bytes C++ LyX.exe!main(int argc, char * * argv) Line 42 + 0x10 bytes C++ LyX.exe!WinMain(HINSTANCE__ * instance, HINSTANCE__ * prevInstance, char * __formal, int cmdShow) Line 131 + 0x12 bytes C++ LyX.exe!__tmainCRTStartup() Line 547 + 0x2c bytes C LyX.exe!WinMainCRTStartup() Line 371 C kernel32.dll!770d33ca() ntdll.dll!77899ed2() ntdll.dll!77899ea5() Regards, Joost
Re: Icons
"Pavel Sanda" wrote in message news:20110223123315.gs26...@atrey.karlin.mff.cuni.cz... Edwin Leuven wrote: ps. does anyone know where the svg sources for the libreoffice icons can be found? at the bottom there are source files http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons for 3.3.1. This is the announcement today: "LibreOffice 3.3.1 also brings new colorful icons based on The Document Foundation branding guidelines" Joost
Re: Commit Do not set all CMake files as C header files.
"Peter Kümmel" wrote in message news:4d655881.9090...@gmx.net... Fixed: http://www.lyx.org/trac/changeset/37776/lyx-devel/trunk Thanks! The text files are still C++ headers now but I guess MSVC ignores those. Joost
Re: Commit Do not set all CMake files as C header files.
"Peter Kümmel" wrote in message news:4d641864.1090...@gmx.net... Here it breaks the merged build. Any idea what's the cause of this issue? It must be related to a certain file type not being set correctly. After the change, all real header files should still be automatically set as headers. And what is the problem when these files are "headers"? For example the .rc file is also set as a header and therefore doesn't compile. Joost
Re: Icons
"Rob Oakes" wrote in message news:a5accdd7-6e23-47c6-9b16-d42583e6b...@oak-tree.us... I spent a little bit of time trying to order the toolbar, based on the conversation from the other day. Here is a first pass attempt which shows the standard toolbar and a revised extras toolbar. Good work! This standard toolbar really focuses on document structuring which is the core feature of LyX, and gets rid of things you don't need when focusing on a document. Improvements such as putting the language tools (spelling, thesaurus) together also make a lot of sense to me. I think a fresh look on the toolbar structure in combination with the icon design is exactly what's needed. Joost
Re: Icons
Pavel Sanda" wrote in message news:20110222172309.ga28...@atrey.karlin.mff.cuni.cz... you didnt get me right. i opposed to definitive killing of old icons for people who get used to them and want to continue using them. in the begining i was silent and prepared to 'fix' it locally for me, but seeing second developer with the same problem is good indication that we will anger some set of long-time users as well. I understand. in other respects i disagree: - there was already request in bugzilla to allow more themes. you just WONTFIX it by claiming that oxygen is the right (TM) icon set. I remember some bug report with unclear wording, maybe I misunderstood. I'm not saying that Oxygen is the only possibility. I think we should design something better and fix the usability issues with the current icons. - i dont see much harm to allow other sets. one more combobox in prefs... I don't agree that adding more options is a good thing. LyX already has too many options. Adding one more may seem like an easy fix, but if we keep accumulating more and more settings things get more complicated for users and more difficult for developers to maintain. Especially the maintenance of icons will take a lot of time which cannot be spend on e.g. new features. Sometimes I think it's up to the developers to find a reasonable compromise, rather than to ask all users to make yet another decision. my reasons are not useful for future designs and its not reasoning, but feeling. i dont feel any disturbance with the current set so why to suffer from reprogramming my mind maps for new toolbars. Right, so if I understand correctly it's mostly about design? Do you agree about the usability issues with the current icons? Joost
Re: Icons
"Vincent van Ravesteijn" wrote in message news:AANLkTino30Rzx3ZPti9G=h6uuvxrvmzv3wnaumaus...@mail.gmail.com... Personally I was more happy with Edwin's set than the oxygen set, but that is just based on taste. Is anyone planning to design a complete icon set for the standard toolbars based on this LibreOffice style? Joost
Re: Icons
"Pavel Sanda" wrote in message news:20110222152505.gm26...@atrey.karlin.mff.cuni.cz... as expected with the ui attempts majority of devs is hard to get. as i count 2 dev against oxygen, third one rather created his own set ;) Still I think it's good to hear the opinion of some more people outside this discussion. I'd also be interested to hear why you oppose the change of icons. Obviously you think the current icons are better, but could you elaborate a bit more? Some of problems with the old icons are (which is why Jürgen and I decided to propose new ones): * Insert icons unclear (cross-reference/citation/index/nomenclature...). E.g. many users think of a citation when seeing the book metaphor in the cross-reference icon. * Icons are nearly invisible with darker window themes (lack of contrast, no outlines) * Float icons difficult to distinguish from icons for graphics/table itself * Mix of different styles * KDE 2 style doesn't match modern operating systems If you could describe some reasons why you prefer the current icons, that would be useful to maybe find a compromise or to take into account in future designs. Joost
Re: Commit Do not set all CMake files as C header files.
"Peter Kümmel" wrote in message news:4d636252.8070...@gmx.net... is definitely wrong. Please revert. This macro is only to add files to the IDE and these files should not influence the build process, therefore the header only flag. Because of this setting they were defined as C++ headers, so they did influence the build process. Now the cmake and txt files are defined as "do not participate in build process", which seems correct to me. Can you explain the problem? Joost
Re: Icons
"Jürgen Spitzmüller" wrote in message news:201102220915.55759.sp...@lyx.org... My proposal, instead of pressing all on one "minimal" toolbar is to further split these toolbars. Then, people can customize the UI to their needs simply by hiding toolbars they do not need. If the view document icon is added to the standard toolbar, the view toolbar can become an optional toolbar like version control and change tracking. Joost
Re: Icons
"Edwin Leuven" wrote in message news:AANLkTi=dh3gj3zqvkwz6gaxeg6qpag-s1ppjddr7z...@mail.gmail.com... On Sun, Feb 20, 2011 at 15:36, Joost Verburg wrote: Here's the new icon set I worked on with Jürgen! It's based on the Oxygen style. attached some idea how it would look like with 16x16 icons from libreoffice... LibreOffice also has nice icons which are much better as compared to our current icons. In this example, many icons are missing or don't really match the feature. The question is whether someone is able and willing to design a complete icon set for at least the standard toolbars. Because LyX is a smaller project we do need to consider the availability of standard icons. The Oxygen icons are used by many applications and therefore a large number of professionally designed icons is already available. The best option is of course to have a professional designer create a full icon set tailored to LyX. However I don't think that's realistic unless we find a really good sponsor. Joost
Re: Icons
"Rob Oakes" wrote in message news:0a5aac7a-2fd2-4e25-9834-39e61557c...@oak-tree.us... If we're going to give LyX a fresh coat of paint, why don't we deal with some of the other UI concerns as well. For example, in addition to improving the visual consistency of the icons, why not simplify the toolbars. (The menus are already very well organized and laid out.) There's definitely a lot of room for improvement in the toolbar and UI design. When I first started using LyX, the sheer number of these options was overwhelming. Now, I've adapted and they don't overwhelm me as much. But the designers I talked to all had a single question on first encountering the UI, "What do all the buttons do?" Moreover, it's not always clear what related icons do, for example, the people I introduce to LyX don't seem to understand which option inserts a float versus an actual image. A second weakness is that there are multiple ways to do the same things. For example, all of the insets can also be added from the "Insert" menu (for which there are usually convenient shortcuts that can speed things up). I had the same problems when I first started using LyX. After a while, you kind of get used to the UI but it remains too complicated. In most traditional toolbar/menu UIs, there will be some features which can be accessed using both menus and toolbars. However in this design, toolbars should only contain commonly used features. The float icons are an example of bad icons in the current UI. I often click the wrong icon because they are too similar to the table/figure icons. This is one of the things we tried to improve with the new icons I can never remember which is supposed to be a cross reference versus a citation (they're both forms f books), so I just choose the option from the menu. For Linux and Windows users, it's just Alt-I and then choose the desired entry. That I totally recognize! Even after years, I'm always clicking the wrong icons for citation / cross-reference. Again something we considered in the new icon design. Other suggestions are of course welcome. If there is interest, I'd be happy to put together a mockup. If we "modernize" our icons, and reduce our reliance on them, I think it would go a long way to improving the impression LyX has on new users. I agree! Joost
Re: Icons
"Enrico Forestieri" wrote in message news:20110220155614.GE1772@GIOVE... OK. But as we already have a consistent set of icons, why throwing out of the window something that already required a huge amount of work? There could simply be a new option "use the new, shiny, wonderful oxygen icons"? I can definitely understand that you got used to the old icons. I however don't think that any designer would consider them to be consistent. It's basically a mix of different stock icons from the Windows 95/98 and KDE 1/2 era combined with custom ad-hoc designs by developers who introduced a new feature needing an icon. It does not at all match the style of modern operating environments like Windows 7, KDE 4 or GNOME. Just compare LyX with other software like OpenOffice 3 or Microsoft Word 2010 and you'll see what I mean. I think new users will look at this very differently. Also we have to consider future developments. If we stick with the current set, it's never going to be possible to support different icon sizes or other features of modern user interfaces. Nobody is going to redesign this old and inconsistent mix in new sizes for example. Sometimes it's better to make a more radical change which will allow us to move into the right future direction. Surely there remains a lot of room for improvement in the UI and icons, but if these kind of changes never happen we cannot move forward. Anyway, let's wait for some other opinions. Joost
Re: Icons
"Pavel Sanda" wrote in message news:20110220151223.ge26...@atrey.karlin.mff.cuni.cz... we would just create new dir "oxygen", or perhaps someone will prepare "tango" and "win". we would always try to load image from this directory and then have fallback to the old set if image not found. (i have no opinion about the default loaded set). Designing one somewhat consistent set of icons is already a huge amount of work. Introducing more variants will reduce the consistency and make it a lot harder to introduce new toolbars and icons. It think it's better to spend the limited time on one good icon set rather than three sets with lower quality. There's already a tendency in open source products like LyX to introduce way too many options and features because of the personal opinions of all developers. For example, because of this we currently have to maintain three different build systems. I think we should follow the opinion of the majority of users/developers rather than introduce more and more options. Joost
Re: Icons
"Enrico Forestieri" wrote in message news:20110220143302.GB1772@GIOVE... But your argument only holds for a *specific* size, as all other sizes are obtained by scaling that specific size. So, what is the rationale of having 16x16 instead of 18x18 if both are going to be scaled down from the 22x22 size? This is only because the support for 16x16 icons is not yet implemented. The plan is to include multiple icons sizes in the future based on standard sizes. Joost
Re: Icons
"Jürgen Spitzmüller" wrote in message news:201102191746.11671.sp...@lyx.org... I think we should finally stick with the standard sizes (16x16, 22x22, 32x32, 48x48). That is: increase smallIconSize from 14 to 16 and bigIconSize from 26 to 32. Increasing the bigIconSize to 32 does not make sense currently because we don't ship 32x32 icons. Icons aren't scaled up. Increasing the small icons to 16 pixels is a good idea. 14 is way too small and in the future we will be able to ship 16x16 icons based on standard/stock icons. Joost
Re: Icons
"Jürgen Spitzmüller" wrote in message news:201102181239.57022.sp...@lyx.org... Yes. I hacked some together myself. See attachment. They are certainly not masterpieces, I mainly took some elements from existing icons, if possible, to have something halfway matching. Thanks. Do you also have the 22x22 png versions? Joost
Re: Icons
"Jürgen Spitzmüller" wrote in message news:201102181054.36078.sp...@lyx.org... The icons I use are not the latest, I have done this some years back. Note that some (the update PDF/master) are badly self-designed icons, since I did not find anythink appropriate back then. We should use something better instead. The latest released set is here: http://download.kde.org/stable/4.6.0/src/oxygen-icons-4.6.0.tar.bz2 Thanks! This set contains a lot of useful icons. I can't find all icons in your image though. Did you create some yourself (e.g. insert TeX and insert math macro)? Joost
Re: Icons
"Jürgen Spitzmüller" wrote in message news:201102180850.11166.sp...@lyx.org... +1 for Oxygen. It's a very well-designed, large and clean icon set. As a bonus, Lyx would integrate even better into KDE. Where do I find the latest Oxygen set which contains the icons you're using here? Joost
Re: Find & replace in 2.0
"Jürgen Spitzmüller" wrote in message news:201102180855.11402.sp...@lyx.org... -1. I think this simple and fast search method is still of much use besides the big, blown advanced dialog. Currently the dialogs are exactly the same except for the possibility to type non-plain text in the advanced one. Perhaps it'd be good to make the "Quick" search a bit more simple then? Maybe just a search box? Joost
Re: Find & replace in 2.0
"Pavel Sanda" wrote in message
news:20110217231834.gr26...@atrey.karlin.mff.cuni.cz...
i must miss something very basic. what two windows are you talking about?
:)
i see one panel with two workareas and one tab for special settings.
You're right, I was confused myself now by the UI. These texts on the tabs
("Basic" and "Advanced") don't make sense to me. Shouldn't that be renamed
to "Search" and "Settings" or something similar?
just tried some search and no, speed looks fine now. anyway we are still
in a debug mode for this new feature.
I guess if it's stable enough to go in 2.0, it can also replace the old one?
Joost
Re: Icons
"Pavel Sanda" wrote in message news:20110217230252.ga16...@atrey.karlin.mff.cuni.cz... btw aren't those 22 pixels what you get if you just switch to "big" icons via context menu? pavel No, those are much bigger. 32 pixels I believe. Joost
Re: Find & replace in 2.0
"Pavel Sanda" wrote in message news:20110217225227.gp26...@atrey.karlin.mff.cuni.cz... Vincent had plan to move it to firefox-style onliner, but it didn't happened. unless you show me where is the third, i think these two are fine. advanced speed is still not enough. The advanced mode has two windows - basic and advanced. I didn't notice the performance issue of the advanced ones. UI wise it doesn't make sense to have both but I guess we have to wait for better performance then. Joost
Re: Icons
"Pavel Sanda" wrote in message news:20110217224752.go26...@atrey.karlin.mff.cuni.cz... 2.0 is good excuse, but it should happen before RC. i would like to make freeze more strict once we enter it. OK. Let's update the main icons now and leave further updates for 2.1. just side notes: - there are related bugs #3149, #6540. - also manuals need to be fixed. Yes, for 2.1 I'd be good to add support for several icon sizes instead of a single fixed-size PNG. Joost
Re: Icons
"Rob Oakes" wrote in message news:88f13752-72ca-4a77-83f1-13040e951...@oak-tree.us... As a way of starting, you might take a look at some of the icons in the Oxygen set or in the faenza set. We might also look at finding an artist to create a custom set for LyX? Maybe for 2.1? The Ubuntu artwork team has recently been looking for better ways to become involved in upstream projects, perhaps they might be interested in this challenge? If so, I could send them an email and gauge enthusiasm? I agree. For now we can replace some of the really bad icons with nicer ones from a standard set. There will of course always be a need for LyX-specific icons for which it'd be great to have a good designer. I'd say go ahead and ask the Ubuntu artwork team! Joost
Find & replace in 2.0
Hi, I was just checking out some new 2.0 features and noticed we got three find & replace dialogs now: * Find & replace - Quick * Find & replace - Advanced - Basic * Find & replace - Advanced - Advanced This really seems like too much. Could we get rid of the old "Quick" dialog and rename "Advanced Find and Replace" to "Find and Replace"? Regards, Joost
Icons
Hi all, The current LyX toolbar icons are blurred because the default icon size is set to 20x20 pixels, although most of our icons actually are 22x22 (this is a standard size). Also some icons looks quite outdated and have jagged edges. Is it OK if I increase the default size with 2 pixels and try to find some better public domain or GPL icons to replace some of the current ones? I'd be nice to have at least a little bit of UI refresh for 2.0 :) Best, Joost
Re: r37243 - in lyx-devel/trunk/src: . frontends/qt4
On 1/18/2011 3:11 PM, Vincent van Ravesteijn wrote: Do you think this can be handled easily by CMake ? Does it already generate lyxrc.dist for the installer ? The Windows installer generates lyxrc.dist because it needs to contain absolute paths which depend on the installation directory. With Stephan's patch this is no longer necessary so we could put the Windows version in development/Win32/ Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 9:10 PM, Guenter Milde wrote: LyXDir is the location of the "LyX library". With 1.6.x, Help>About LyX displays it as "Libary directory". This discussion was about the program directory, not the library directory. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 1:57 PM, Jean-Marc Lasgouttes wrote: I do not think there is any problem to expect. Are calls to QtCore allowed these days? I noticed a function called applicationDirPath. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 11:27 AM, Stephan Witt wrote: The conclusion is it will not work with batch files. So one should avoid them consequently. I suppose with python scripts we have no problems on windows... Converters that use Python scripts are defined as "python script.py", just like for a batch file you could use "cmd script.bat". Supporting "script.py" or "script.bat" without the name of the application would require the use of the registered file association which is a feature of the Windows shell. Otherwise there's no way to know which application to run. AFAIK it's not simple to implement this combined with the process control required for the multi-threading. The idea of the file association is that you ask the shell to open the file, not control the process yourself. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 11:16 AM, Jean-Marc Lasgouttes wrote: The reason why I never did it after me promises is that I stopped at the question "what is LyXDir exactly?" I failed to find an answer that is useful to windows, OSX and linux. I poor excuse, I know :) I'd say the location of the executable minus the "bin" if present, e.g. "C:\Program Files\LyX20" on Windows. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 11:11 AM, Stephan Witt wrote: This is the portable LyX target? This one I propose to tackle after the standard installation works well. I was trying to avoid using environment variables for the standard installation as well. Environment variables can be user specific or shared by all users. There are different things the installer would have to take into account. In addition there will be issues with installation on shared network drives. Currently in 1.6 there's an additional application (LyXLauncher.exe) which sets the environment variables before running lyx.exe. This is causing troubles with Windows 7 so the idea is to get rid of it in 2.0. It'd be great if LyX could set LyXDir automatically. How can LyX know the correct value? Should it be derived from the path of the executable? Yes. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 11:07 AM, Stephan Witt wrote: I don't get it. LyX has no windows command prompt :-) E.g. to typeset something LyX executes latex... If it's an executable it works obviously. But does it work too, if I make a latex.bat and place in path in front of the regular tex path? Nope, but "cmd.exe latex.bat" works. Windows doesn't have a system like UNIX where the first line of the script contains the location of the shell. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 8:38 AM, Stephan Witt wrote: You are the devils advocate? :-) Seriously, it would help for external .bat/.cmd utilities on windows. But in general it's a good move to refrain from using system(). I don't see a problem with batch files. Batch files are interpreted by the Windows command prompt which is a normal application. Something like "cmd.exe batchfile.bat" should work. Joost
Re: Make lyx more easy to be configed as portable program
On 1/17/2011 8:48 AM, Stephan Witt wrote: Sorry, this was not verbose enough. Here I propose to use LyXDir in lyxrc.dist of windows. E.g. \path_prefix = $LyXDir/bin;$LyXDir/ImageMagick;$LyXDir/python Note the $LyXDir notation. The same holds true for \thesaurusdir_path etc... Then set LyXDir environment to C:/LyXLocation and it should work. Yes, but for example a USB drive will get a different drive letter each time. It'd be great if LyX could set LyXDir automatically. Joost
Re: Make lyx more easy to be configed as portable program
On 1/16/2011 10:16 PM, Stephan Witt wrote: Now I think effectively it's a bug. In the past the external utilities where started with system() calls. Then the shell interpreted the environment variables. This was replaced by QProcess::start. I'm almost sure since then the environment variables has in path_prefix (if existent) will not expanded anymore. If we do it explicitly when calling prependEnvPath() it works for me. Yes, you're right. QProcess doesn't invoke the shell. LyXDir should be a special case though since there is no such environment variable. Currently on Windows it is neccesary to write a path_prefix with absolute paths to the configuration files (e.g. "C:\LyXLocation\ImageMagick") because otherwise LyX won't find the external utilities which are located in separate directories. This makes it impossible to put LyX on a USB drive and complicates the installation and testing process. It would make things a lot easier on Windows if expandPath could look for %LyXDir% and expand this to the LyX directory. Joost
Re: Make lyx more easy to be configed as portable program
On 1/16/2011 8:41 PM, Stephan Witt wrote: LyX uses QProcess to create child processes. I cannot tell for sure if the PATH environment with %LyXDir% included works. I could not find it when reading the Qt docs here: http://doc.qt.nokia.com/latest/qprocess.html Can you give it a try please? I don't have windows. I'll test it on Unix. Right, I thought that %LyXDir% would actually be expanded by LyX itself but this isn't the case. On Windows the LyX directory contains a "bin" directory with LyX itself, an "ImageMagick" directory, a "python" directory etc. So currently it's impossible to move the LyX directory without breaking the link to these bundled applications. The installer also has to update the configuration files depending on the installation location. Would it be possible to add LyXDir as a special case to expandPath? This could be for Windows only if it's not relevant on UNIX. Joost
Re: Make lyx more easy to be configed as portable program
On 1/16/2011 5:11 PM, Stephan Witt wrote: In addition a call to expandPath should be added for path_prefix. ... I wonder why that is of any use. If I change my path_prefix in the preferences I don't expect it gets replaced immediately. Instead of this I expect it to be replaced at runtime. Yes that's exactly what I mean. It should be replaced at run-time, not in the preferences like in the previous patch. If this is already the case (i.e. I can use %LyXDir% in lyxrc.dist) no additional changes are needed. Joost
Re: Make lyx more easy to be configed as portable program
On 1/16/2011 4:12 PM, Pavel Sanda wrote: so it depends whether the guys are satisfied with this. pavel Stephan's patch looks fine to me. In addition a call to expandPath should be added for path_prefix. Joost
Re: Make lyx more easy to be configed as portable program
On 1/14/2011 11:23 PM, Pavel Sanda wrote: unless somebody is going to make detail review, this is too late for 2.0. it can bring regressions since the code touches common routine... Some time ago I mentioned this exact same issue on the devel list. It would make the development of a Windows installer a lot easier if it could be fixed in 2.0. If you can find some time to review this patch I'd really appreciate that. Joost
Re: Towards beta3 and beyond
On 12/22/2010 7:31 PM, Uwe Stöhr wrote: Could you at least take care that there are installers available for further LyX releases until I'm back. I can try to build my installer from abroad, but I cannot promise this. I don't expect to have time to write a new installer for 2.0 in Jan-Feb. Also I'm not planning to write something alone because this will create the same problems as we're having right now. This year we agreed to build a new installer _together_ which we both will be familiar with. Unfortunately I haven't heard from you in the meantime and thus will have the same problem with your new installer that I would need a lot of time to be able to fix possible bugs in it. For now I would ask you to provide e.g. LyX 2.0 rc3 or current SVN (has to be this year) with your new installer as big ZIP-file for me. This way I can at least use my installer but benefit for now from your work concerning Hunspell and the like. There is no new installer yet for 2.0. All the work related to CMake and the new libraries is now finished and available on the devel FTP. Writing a new installer that uses this new stuff is what still needs to be done. This is what I wanted to discuss. Given the fact that we will both be very busy in the next months I guess it will have to wait until March. Joost
Re: Towards beta3 and beyond
On 12/21/2010 4:39 PM, veno...@arcadiaclub.com wrote: That's why I think more people should be involved so that Uwe, myself and maybe some others will at least be reasonable familiar with the code. If you give me all the necessary info maybe I can help and familiarize with NSIS. I'm pretty experienced under Windows, but never get in touch with NSIS. Jost, could you point me out, where can I collect all the necessary information? Thanks! I would suggest browsing http://nsis.sourceforge.net/Docs/ and http://nsis.sourceforge.net/Developer_Center Joost
Re: Towards beta3 and beyond
On 12/20/2010 7:40 PM, Pavel Sanda wrote: although all the advantages above look like very good step forward i'm afraid there is nobody around who is going to write new NSIS code (i suppose Uwe is not going to leave his code for some unfinished stuff he is not familiar with.) That's why I think more people should be involved so that Uwe, myself and maybe some others will at least be reasonable familiar with the code. so more direct question would be whether you intend at least continue the old standard installer... I find the current situation with different types of installers way too confusing for users. I don't think it's helping the LyX project. There are features in the standard installer which I think are import such as not requiring administrator privileges. Also the way I bundle external applications (ImageMagick/Ghostscript) I think is more reliable. They are private to LyX, I don't modify registry keys that are supposed to belong to the original applications. But the disadvantage of having two different installers might outweigh this. I still believe the best way forward is to start with the CMake build tools and the new libraries I've recently ported to Visual C++ (ftp://ftp.devel.lyx.org/pub/contrib/windows/). Then LyX can be compiled as a real Windows GUI application. Based on that it shouldn't be too hard to create an easy to understand installer script. It would require some major updates anyway to get rid of the old launcher process and to replace the spell checking / thesaurus libraries. So starting with a new script would be a sensible thing to do. The question is whether this is feasible for 2.0. Perhaps I could start with build instructions and a really basic installer script that does only what's necessary to install LyX itself. From there we could continue to add new features. However before doing anything like that we have to be sure everyone agrees with this approach. Joost
Re: Towards beta3 and beyond
On 12/20/2010 6:48 PM, Pavel Sanda wrote: - windows installers. Joost, are there some advances in the announced 'joint' installer, so we no more proceed with the doublet official/alternative? or do we continue with the current 1.6 model? any way we should start to offer *some* official installer in case you plan to continue contributing it. The basic framework is in place. With the new CMake build tools, the updates to the external process calling and updated external libraries, a LyX version can be compiled that works standalone without a separate launcher app or any registry keys for ImageMagick/Ghostscript etc. Everything is now also fully compatible with the latest Visual C++ 2010. This means that clicking lyx.exe will directly start the real LyX with all the right settings. So no problems with the Windows 7 taskbar anymore. I think we should definately switch from Aspell / Aiksaurus to Hunspell / MyThes. This will also make the distribution easier (no Aspell installer to bundle). What needs to be done is to write the NSIS code to generate the actual installers, which will be less code than what we currently have because of the before mentioned. I'd strongly prefer a situation in which multiple developers are able to generate official Windows releases. Perhaps Uwe could become the main Windows release manager if he wants to, because he's always quick with the new releases. Unfortunately my current job keeps me extremely busy so I'm not sure when I'll have time to work on this. I will try to start working on some documentation for the build process so Uwe and other people will also be able to compile LyX with the latest versions of the external dependencies (gettext/iconv/hunspell/mythes etc.). Joost
Re: no spellcheck after win installer 1.6.8
Yes, I'm working on a fixed version. Joost On 11/21/2010 4:19 PM, Edwin Leuven wrote: see subject: can anyone confirm? thanks, ed.
