No RichEdit20A window class
Just for the record, I'm still trying to develop a proper RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think. If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at: http://foltman.com/riched.zip I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable. What IS done: - basic text wrapping with support for proportional fonts and character formatting, no major known bugs (the only supported attribute is Bold, but the rest will be relatively easy to add) - simple editing (typing text, backspace, delete, no overwrite mode yet) - a very incomplete implementation of Shift-arrow selection (done in a few hours yesterday :-) ), mouse operations don't support selection yet - per-paragraph alignment - pitiful low-level style management - bold attribute - some basic optimizations (avoiding rewrapping unmodified paragraphs unless editor window is resized) - uses UNICODE internally (not necessarily a good thing) What isn't done: - RichEdit API (which is a mess; I'm taking care of it in order to ensure compatibility wrt how editing functions work, however, basic editing functionality is the number one priority, as it's more difficult to achieve) - RTF interface - Undo - Clipboard - tabs - bulleted lists - setting paragraph attributes (margins are implemented internally but can't be changed with current interface, setting alignment by Ctrl+L/E/R works) - all RichEdit f3 functionality - MBCS support (and it would be very hard to add) - BiDi and CTL support (ditto) - everything not mentioned in the first list Krzysztof
Re: Winecfg - browse for folder
Mike Hearn wrote: On Thu, 25 Nov 2004 14:42:24 +0100, Robert van Herk wrote: 3. Nice, but we loose strict win32 compatibility, since there will be a magic flags that doesn't exist in win32. This is the most lightweight so I'd go for it for now. If we find that the flag value we pick is already in use we can just change it, no big deal. We already use custom Wine flags in other parts of the code (eg WS_EX_TRAYWINDOW). Internally though, the SHBrowseForFolder dialog (dlls/shell32/brsfolder.c) uses pidls, which, as far as I know, are a specific win32 thing for identifying paths uniqually. Thus, if I'd make an extra flag in the dialog, I would have to extent pidls to, so that they can hold unix paths. Is that a wise thing to do? Or should I take another approach? Robert
Re: No RichEdit20A window class
Krzysztof Foltman wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: No RichEdit20A window class
Shachar Shemesh wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? I am. However, I've assumed that one character = one wchar_t, and there are no prefix/suffix non-printable characters. However, I'm speaking about encodings where character size may vary depending on a character. Like using utf-8 internally. All string operations (even benign ones like calculating number of characters) become much more complex, instead of O(1) mapping between character index (in characters) and character offset (in bytes or words), we have O(N). Chris
Re: No RichEdit20A window class
I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq that others can help work on it. I'm quite interested to see the source for this. Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later, so long as you are the sole author. I think you'll find that the development proceeds much quicker if you release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features. When you do release your completed riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code. Frankly speaking, people promising to release their source code at a later date is an impedement to development, because nobody is motivated to work on the promised feature in the mean time. Please consider release early, release often, so we can work together on this :) Mike Krzysztof Foltman wrote: Just for the record, I'm still trying to develop a proper RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think. If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at: http://foltman.com/riched.zip I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable. What IS done: - basic text wrapping with support for proportional fonts and character formatting, no major known bugs (the only supported attribute is Bold, but the rest will be relatively easy to add) - simple editing (typing text, backspace, delete, no overwrite mode yet) - a very incomplete implementation of Shift-arrow selection (done in a few hours yesterday :-) ), mouse operations don't support selection yet - per-paragraph alignment - pitiful low-level style management - bold attribute - some basic optimizations (avoiding rewrapping unmodified paragraphs unless editor window is resized) - uses UNICODE internally (not necessarily a good thing) What isn't done: - RichEdit API (which is a mess; I'm taking care of it in order to ensure compatibility wrt how editing functions work, however, basic editing functionality is the number one priority, as it's more difficult to achieve) - RTF interface - Undo - Clipboard - tabs - bulleted lists - setting paragraph attributes (margins are implemented internally but can't be changed with current interface, setting alignment by Ctrl+L/E/R works) - all RichEdit f3 functionality - MBCS support (and it would be very hard to add) - BiDi and CTL support (ditto) - everything not mentioned in the first list Krzysztof
Re: No RichEdit20A window class
Mike McCormack wrote: I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq that others can help work on it. I'm quite interested to see the source for this. I may send the source code to people who are potentially interested, so that it may get taken over if I get very busy or bored of it, and so they can make up their minds about if the design and the actual code is good enough for WINE. Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later, I think I'll dual license it (LGPL/BSD). I can think of some closed source applications (freeware or not) that would definitely benefit from a free rich text editor that doesn't suck as much as RICHEDIT20 does. However, straight LGPL would be OK too, if BSD puts anybody off. so long as you are the sole author. That's where part of the problem is: as long as someone sends me just a Ctrl-arrow patch, I can always be suspected of stealing that patch. It puts me in a very uncomfortable position. release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features. I'm not going to wait until it's finished, I just don't want people to add features that must be removed or rewritten a week later because of half of functions have their parameters changed. For example, adding Undo functionality from scratch after everything else is done would be a disaster. When you do release your completed riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code. Another reason not to accept patches just now. Luckily, a commercial version (made for particular use in two or three applications of a particular company) will be actually very simple, having little more features than it has now, and no RICHEDIT API at all. After that, I may safely fork the source. Frankly speaking, people promising to release their source code at a later date is an impedement to development, because nobody is motivated to work on the promised feature in the mean time. That's what I'm afraid of, too. I'm currently thinking of solutions for that problem. Please consider release early, release often, so we can work together on this :) I agree, this project has a lot of space for collaboration. For example, achieving high degree of compatibility with RICHEDIT will require a lot of reverse engineering and finetuning. However, doing advanced features with basic architecture screwed up is not going to work. Krzysztof
Re: Winecfg - browse for folder
On Sat, 27 Nov 2004 10:37:10 +0100, Robert van Herk wrote:
Thus, if I'd make an extra flag in the dialog, I would have to extent
pidls to, so that they can hold unix paths. Is that a wise thing to do?
Or should I take another approach?
Hmm, I'm not sure you want to do that. You may wish to abstract that out,
eg replace the parts where PIDLs are passed around with a
struct path
{
PIDL pidl;
char *path;
}
then use whichever is non-NULL. Extending PIDLs is possible but probably
would get a bit icky.
Fun desktop integration tasks
Hi everybody, I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop. None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved. As usual no guarantees these patches would be accepted, that's Alexandres call. But they probably would be, and you'll learn something while doing them! :) Task 1: Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this. I think it'd be ok to grab $HOME using the UNIX getenv() and then using the libwine APIs to map them to a Win32 path. If the mapping fails (ie $HOME is not accessible given the users dosdevices) then just fail with a WARN(). Task 2: This is similar to above but with some extra work. Map the contents of the ~/Desktop directory to the Windows virtual Desktop folder. In file pickers and Explorer, the filesystem root is represented by a magic Desktop folder. In real Windows this reflects the icons that are on the desktop and is mapped to a real directory at some arbitrary point in the filing system. On Linux we have no such virtual root, however it'd be nice if icons that appeared in the KDE/GNOME desktop were put in their proper place. That way users won't be confused by the file being on their desktop but unavailable from their Windows applications file picker. This should not be too hard. The Desktop folder is implemented by a COM object in dlls/shell32/shfldr_desktop.c. You just need to read the $HOME/Desktop folder and put the items you find in there inside. Ignore .desktop files for now, they are a bit tricker to map and aren't especially useful for us anyway. You also want to map CSIDL_DESKTOP in dlls/shell32/shellpath.c, _SHGetDefaultValue. See above. Bonus points for fixing the desktop icon while you're at it (an arrow??!) Task 3: The freedesktop.org icon theme specification shows us how to find icons for many different types of thing. Implement support for loading and using the following icons from the icon theme (it should be OK to use native libraries for this like GdkPixbuf, just fall back to the compiled in defaults if it's missing): - folder - desktop - computer - unknown document - any others?? Don't do file types, as native icon-file type association is done by mime types not extensions, and it'd make our file dialogs even slower than they already are. You may be tempted to use eg, libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG. Task 4: Try updating the menu mapping code to support the new XDG menu specification. Don't bother trying to make this work everywhere, it's a total nightmare. Just try supporting the new standards. Be warned: not every desktop/distro supports this yet! This one might be quite hard. Task 5: Try improving the winebrowser script to take into account the users preferred applications. At the moment it just tries every browser it knows about in a hard coded order. Hint: in modern GNOME desktops you can use the gnome-open program to make this automatic. There is a KDE equivalent. Task 6: Integrate Wine with XScreensaver, so installing Win32 screensavers makes them automatically appear in the list. You may need to write patches for xscreensaver to make this really slick. Have fun! thanks -mike
Re: Fun desktop integration tasks
On Sat, 27 Nov 2004 21:14:33 +, Mike Hearn wrote: You may be tempted to use eg, libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG. Actually it's probably easier to use the new GTK+ APIs to implement this, that takes care of not only rendering the image to a raw bitmap you can then convert to an HICON, but it also implements the icon lookup algorithm for you. In future it'll probably also implement some fancy caching mechanism to reduce memory overhead. Might as well get these benefits easily! thanks -mike
Re: Resend: Re-implement MSVCRT *printf functions
Well I recently got re-motivated, by forgetting I was using an unpatched
version of Wine, and getting my WC3 campaign file nuked :(.
So, I've had a go over this all, and here is a new version. Is it a step
in the right direction? I still don't really know what I should be doing
to improve this.
Aneurin Price
Index: dlls/msvcrt/Makefile.in
===
RCS file: /home/wine/wine/dlls/msvcrt/Makefile.in,v
retrieving revision 1.17
diff -u -u -r1.17 Makefile.in
--- dlls/msvcrt/Makefile.in 8 Nov 2004 22:10:43 - 1.17
+++ dlls/msvcrt/Makefile.in 27 Nov 2004 21:27:58 -
@@ -27,6 +27,7 @@
math.c \
mbcs.c \
misc.c \
+ printf.c \
process.c \
scanf.c \
string.c \
Index: dlls/msvcrt/file.c
===
RCS file: /home/wine/wine/dlls/msvcrt/file.c,v
retrieving revision 1.73
diff -u -u -r1.73 file.c
--- dlls/msvcrt/file.c 3 Nov 2004 22:17:05 - 1.73
+++ dlls/msvcrt/file.c 27 Nov 2004 21:28:00 -
@@ -2614,113 +2614,6 @@
return file;
}
-/*
- * vfprintf (MSVCRT.@)
- */
-int MSVCRT_vfprintf(MSVCRT_FILE* file, const char *format, va_list valist)
-{
- char buf[2048], *mem = buf;
- int written, resize = sizeof(buf), retval;
- /* There are two conventions for vsnprintf failing:
- * Return -1 if we truncated, or
- * Return the number of bytes that would have been written
- * The code below handles both cases
- */
- while ((written = vsnprintf(mem, resize, format, valist)) == -1 ||
- written resize)
- {
-resize = (written == -1 ? resize * 2 : written + 1);
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (char *)MSVCRT_malloc(resize)))
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vfwprintf (MSVCRT.@)
- * FIXME:
- * Is final char included in written (then resize is too big) or not
- * (then we must test for equality too)?
- */
-int MSVCRT_vfwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, va_list
valist)
-{
- MSVCRT_wchar_t buf[2048], *mem = buf;
- int written, resize = sizeof(buf) / sizeof(MSVCRT_wchar_t), retval;
- /* See vfprintf comments */
- while ((written = _vsnwprintf(mem, resize, format, valist)) == -1 ||
- written resize)
- {
-resize = (written == -1 ? resize * 2 : written + sizeof(MSVCRT_wchar_t));
-if (mem != buf)
- MSVCRT_free (mem);
-if (!(mem = (MSVCRT_wchar_t *)MSVCRT_malloc(resize*sizeof(*mem
- return MSVCRT_EOF;
- }
- retval = MSVCRT_fwrite(mem, sizeof(*mem), written, file);
- if (mem != buf)
-MSVCRT_free (mem);
- return retval;
-}
-
-/*
- * vprintf (MSVCRT.@)
- */
-int MSVCRT_vprintf(const char *format, va_list valist)
-{
- return MSVCRT_vfprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * vwprintf (MSVCRT.@)
- */
-int MSVCRT_vwprintf(const MSVCRT_wchar_t *format, va_list valist)
-{
- return MSVCRT_vfwprintf(MSVCRT_stdout,format,valist);
-}
-
-/*
- * fprintf (MSVCRT.@)
- */
-int MSVCRT_fprintf(MSVCRT_FILE* file, const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * fwprintf (MSVCRT.@)
- */
-int MSVCRT_fwprintf(MSVCRT_FILE* file, const MSVCRT_wchar_t *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfwprintf(file, format, valist);
-va_end(valist);
-return res;
-}
-
-/*
- * printf (MSVCRT.@)
- */
-int MSVCRT_printf(const char *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vfprintf(MSVCRT_stdout, format, valist);
-va_end(valist);
-return res;
-}
/*
* ungetc (MSVCRT.@)
@@ -2753,17 +2646,4 @@
return MSVCRT_WEOF;
}
return mwc;
-}
-
-/*
- * wprintf (MSVCRT.@)
- */
-int MSVCRT_wprintf(const MSVCRT_wchar_t *format, ...)
-{
-va_list valist;
-int res;
-va_start(valist, format);
-res = MSVCRT_vwprintf(format, valist);
-va_end(valist);
-return res;
}
Index:
Re: Fun desktop integration tasks
On Saturday 27 November 2004 22:14, Mike Hearn wrote: Hint: in modern GNOME desktops you can use the gnome-open program to make this automatic. There is a KDE equivalent. In kde the command is 'kfmclient openUrl url'. -- Diego Flameeyes Petten [EMAIL PROTECTED] - http://flameeyes.web.ctonet.it/ pgpuLGH3IVwVa.pgp Description: PGP signature
Re: Fun desktop integration tasks
Hi Mike, --- Mike Hearn [EMAIL PROTECTED] wrote: Task 1: Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this. You left the most important thing off the list g. I would like to add support to use the draft FreeDesktop trashcan spec. I am working on this a little with one of the ReactOS guys but it will be a while before we have a patch ready. Thanks Steven __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Translate dir names into Spanish
Hi I have some programs in spanish for windows but when i install it i have problems with dir names, for example Program Files is Archivos de programa, Common Files is Archivos comunes, and so. Can i translate this names in source and compiling without problem?? which files i need update?? Can i translate Wine into spanish?? How? Regards Joaquín -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -END PGP PUBLIC KEY BLOCK-
Changed IE6 install script to run IE6 completely out-of-box
As mentioned in WWN #250 : (BIf you dissect the script you'll notice a lot of what it does is (Binstall some proprietary DLL's. Specifically, DCOM98, MFC 4.0, (Band Microsoft Installer. So yes, it's cheating and Wine isn't running (Bthese completely out of the box. However, you can run them. (B (BI changed the install script a bit and it does not depend on DCOM98, (BMFC4.0, etc... anymore. (BSo, you can run IE6 completely out-of-box. (B (BNew script is here : (Bhttp://sidenet.ddo.jp/winetips/files/wine-config-sidenet-1.5.3.tgz
