Makes perfect sense. As for the unnecessary checks, I was fixing these in my own code, and some of the checks were also in the improved FSB that you wrote for me, I have checked if the same "problem" also occurred in xnedit. So I reported it, not trying to be smart.
code style: do not check pointer before free()
For me, it works perfectly as it is now. Thank you!
Thank you very much. Sorry for not testing the latest version from git. Actually saving files from all windows is the desired functionality. But I agree that it is a little dangerous if used carelessly, maybe it requires a warning with confirmation.
Save all?
Nice patch, Peter, I am stealing it for use in my code. One small improvement possibility: instead of static const char request_code[256] use static const char request_code[] and then on usage do request_code[min(128,number)] it is not time critical and saves a couple of bytes.
Fantastic, that was the quickest bugfix in the history! I confirm that the problem is solved.
I have used the latest xnedit On OpenSuse Linux 15.0, Firefox 68.2 while writing a mail in gmail, I select with mouse the following text (without quotes, without new line character) "Blabla blaž blaž blaž blaž blaž" then, without using copy from menu in Firefox, I simply paste the text into fresh xnedit with middle mouse button (not from paste menu in xnedit). I attach the image of the crash trace from ddd, which shows the exact position of the crash (but maybe memory is corrupted before). It may...
I think it is not possible. On program startup, it reads the various settings, like text color, background color, shadow color... Then it uses the same 24 bit or 32 bit pixel value to draw the Widgets. If you change the default colors, the client programs are not notified, so they continue to use the old color values. Only on logout/login, you get the new colors, since settings are re-read. If all programs would be written using the similar toolkits, and if toolkits would provide some protocol to...
Probably the graphics system was 8-bit with 256 color palette. Changing the color palette would immediately change the color immediately where the same pixel value was used. So there is no need to refresh the whole graphics screen, just change the palette. The palette system also caused the programs to compete for color palette entries. The window manager would use 30 or so colors for text and window decoration, while the others were available for the other programs. If the system ran out of colors,...
Probably the graphics system was 8-bit with 256 color palette. Changing the color palette would immediately change the color immediately where the same pixel value was used. So there is no need to refresh the whole graphics screen, just change the palette. The palette system also caused the programs to compete for color palette entries. The graphics system would use 30 or so colors for text and window decoration, while the others were available for the other programs. If the system ran out of colors,...
And you can also use shortcuts "Ctrl +" and "Ctrl -" to change font size on the fly. This can be useful as you change display from one monitor to another.
And you can also use shortcuts "Ctrl +" and "Ctrl +" to change font size on the fly. This can be useful as you change display from one monitor to another.
Thank you for accepting the suggestion and implementing it so quickly! It works just the way I need it.
I regularly use xnedit on many files in parallel. The efficiency of xnedit in doing that is one of its many strong points. Often, I iconize some windows to reduce the clutter or indicate the files on which I have already finished the modifications. Window manager indicates iconized windows to some extent, but xnedit does not. Currently, xnedit indicates modified files in the Windows menu with asterisk, which is very nice. Would it be possible to put iconized windows in parenthesis, so that one can...
It is saved in the callback, and SelectViewItemDestroy frees it.
I have the following code static void AddViewMenuItem(XnFileSelectionBox w, const char *name, int viewIndex) { Arg args[4]; int n = 0; XmString label = XmStringCreateLocalized((char*)name); XtSetArg(args[n], XmNlabelString, label); n++; XtSetArg(args[1], XmNpositionIndex, w->fsb.selectedview == w->fsb.numviews ? 0 : w->fsb.numviews+1); n++; Widget item = XmCreatePushButton(w->fsb.viewMenu, "menuitem", args, n); if(viewIndex == 0) { w->fsb.viewSelectorList = item; } else if(viewIndex == 1) { w->fsb.viewSelectorDetail...
X/Open Common Desktop Environment(XCDE) Definitions and Infrastructure https://pubs.opengroup.org/onlinepubs/009667599/toc.pdf X/Open Common Desktop Environment(XCDE) Services and Applications https://pubs.opengroup.org/onlinepubs/009667699/toc.pdf
According to my understanding, the style warning is correct. You can safely omit the "temp>=152" condition and get the same behavior on all input values.
Thanks for the update, really useful.
Thanks for the update, really useful updates.
Is anybody else experiencing huge slowdown in the latest version? I understand gradual slowdown due to larger feature set, but not a ten-fold slowdown. My project is mid-size, 180.000 lines of C code. My command line is: cppcheck --max-configs=1 --enable=all --std=c99 .c .h The slowdown is extreme on larger modules (>20.000 lines) cppcheck 1.83 real 1m7.098s user 1m7.048s sys 0m0.048s cppcheck 2.3 real 1m36.737s user 1m36.415s sys 0m0.072s cppheck 2.5 real 16m1.705s user 16m1.356s sys 0m0.093s My...
It could be that the query with which xnedit is asking the system for available fonts is too relaxed. In util/fontsel.c, we have a function UpdateFontList Maybe we should explicitly request scalable fonts, so we don't get bitmap fonts. FcObjectSetAdd(os, FC_SCALABLE); <<< insert this line sel->list = FcFontList(NULL, sel->filter, os);
It is not a bug. Bitmap X11 fonts have a completely different naming scheme compared to XFT fonts, which are anti-aliased and mostly support UTF8. So font selector respects that, and gives you a different user interface, as well as showing you a different set of fonts. Bold and italic fonts can be generated automatically on XFT, while with bitmaps fonts, they have to exist (be drawn or rendered), or they will be absent from the list. So user need to select bold and italic version of font manually...
Drag-and-drop works correctly the first time; the selected file gets opened, or if we already have an open file, it opens new window with that file. But if you then select a different file and drop it again on the first xnedit window, nothing happens. This is because drag-and-drop is getting again the first file. But if we drop it to another xnedit, it opens the correct newly selected file. It looks as if xnedit drag-and-drop would be locked by the first file dropped. In my opinion, this is probably...
I agree with you that backlighting should have higher priority. In my usage, cursor line color is just an enhancement to find cursor position even faster (it is actually very small on 4K display). But backlighting is giving me information about correct space usage, which is important exactly at the point of editing. It would be nonsense if I had to move the cursor to different line just in order to see if whitespace is comprised of spaces or tabs.
Since you mention font size, do you know that you can use Ctrl +- to change font size on the fly, even without going into any settings? Finally the flexibility of XFT can help us preserve the eyesight.
Since you mention font size, do you know that you can use Ctrl +- to change font size on the fly, even without going into any settings. Finally the flexibility of XFT can help us preserve the eyesight.
I have compiled the new version from current snapshot and both indent rainbow as highlight cursor line work. It is a relatively simple but very effective visual aid.
Thank you for your quick reply. At the moment, my knowledge of internal working of cppcheck is too shallow to be able to contribute a feature like this. I have a backlog, since I have spent so much time in diagnosing a stupid memcpy bug, which only happened on customers' computers, and we could not reproduce on our development system. Due to different implementation of memcpy on customer's computers, but with same program binary.
Would it be possible to add a check to detect (possible) overlap on memcpy? If source and destination overlap, the result is undefined. On some implementations it works same as programmer expected, like memmove, on some it will not. #include <stdio.h> #include <string.h> int main () { char buff[] = "0123456789"; printf("Before memcpy %s\n", buff); memcpy(&buff[2], &buff[1], 5); printf("After memcpy %s\n", buff); return(0); } Currently cppcheck does not report any warning or error on such code. If...
@tksoh - I am using the latest snapshot of xnedit, https://sourceforge.net/p/xnedit/code/ci/master/tree/ and it shows Asian characters corectly (traditional and simplified Chinese, Thai). Works on Linux and on Mac. Do you have the fonts installed on your system? Which system are you using? Did you try to change the font in settings?
Hello Fethi, No, I could not get L1800 to work properly with Gutenprint. In the end, I had to install Epson printer drivers from here: http://download.ebz.epson.net/dsc/search/01/search/searchModule I would much prefer to use Gutenprint, but I can't.
It can be frustrating at this stage, since 90% of code is old and many approaches which were OK in 1995 are not considered good practice in 2020. So there is a lot of work to clean old code, and then you benefit from high quality report of subtle bugs. And this refactoring can also introduce new bugs. Here is the command I use to check the source. cppcheck --library=motif.cfg --platform=unix64 --std=c99 --max-configs=3 --enable=all .c .h 2>report.txt
Thanks, I have added some issues reported by cppcheck. There are many, but I only report the ones which are more serious, in my opinion. And the ones where I can suggest a solution.
I see that you did the detail view in file selection box. I can confirm that it works on Linux, it is fast on large workloads. Maybe some small refinements in user interface will be added later, but 98% of the functionality is already there. Congratulations for making this editor much more useful.
Great! I can confirm that it now works correctly on the test cases of 18 laguage translations of my software.
The line 1420 return FALSE; shold be changed to fclose(fp); return FALSE; Reported by cppcheck.
Line 725 return FALSE; should be NEditFree(fileString); return FALSE; Found by cppcheck.
In the attachment, there is one text file which behaves strangely if loaded in latest xnedit from master (feb 4, 2020). Xnedit claims that it contains 3 unconvertable characters and they are skipped, with a waring on top of the interface. This is the offending line in xnedit <value>MD<name>???代尔纤维</name></value> but it is perfectly OK in kate <value>MD<name>莫代尔纤维</name></value> Strangely enough, it is also displays correctly in xnedit, if I only insert this line in a separate file. Other UTF-8 capable...
Is there any hope to get the detail view (name, date, filesize; with sorting) in file selection box? You have done some initial work, but i see that in the latest version it has been removed.
Thank you for sacrificing you weeked, so we can fix our code using this wonderful tool next week.
I also got the printout, but printouts were horrible, colors totally off... Calibration can only find colors which the printer is already printing, if the colors are not there, it can not create them. So normal uncalibrated print must already be relatively linear and with large gamut. I have my own color calibration software, I measure colors with Spectrolino table robot. Usually I can reuse the profiles if we have A4 and A3 versions of the printer. Since L1800 is A3 version of L800/L805, I was expecting...
Epson L1800 misclassified, not printing properly
I have managed to compile xnedit on Mac OS X Catalina with Motif from homebrew using the attached makefile. If you like it, you can add it to the distribution.
Nice progress! Could you make Ctrl++/Ctrl+- also work with numerical keyboard? On many nationaly keyboards, + and - are on different places, sometimes available with shift, so using +- from numerical keyboard is easier nad more intuitive, since + and - are next to each other.
I can confirm that the latest version new FSB speed is fantastic on large number of files. Thank you for this fix, I am sure it will be apreciated by some other users in the future. My offer to support development with better list FSB still stands, if you are interested, contact me privately.
The old Motif FSB, however spartan, is old and tested code which went through a lot of stress tests. So it behaves well in unusual conditions. In my experience, the local I/O on SSD is very fast on Linux. The second time I enter in a directory with thousands of files, it is practically instant due to caching. The bottleneck is usually GUI, if programmer tried to make things interactive, add objects one by one and refreshing the contents. Dolphin in KDE works like that, and it becomes useless as file...
Thank you for fixing this behavior of the new FSB! I also use the old one for several reasons: 1) I compile both to test behavior and regressions. 2) The new FSB has poor performance on directories with large number of files (10.000+) in list view, a couple of seconds compared to instant in old Moti f FSB. 3) The new FSB has poor performance on directories with large number of files (10.000+) in icon view, can take 10 seconds to fill in, and on big directories it will exit with this error: X Error...
When I call Files > Save as... the previous filename is not present in "New File Name" field or in selection field in the old Motif file selecion box. Usually it is better to keep the old name, so that we can edit it before saving. An old motif bug also clears the filename selection as you change directories. Also a major annoyance, when you wish to save the filename with same name, but to a different directory.
I can confirm your observation that XFT fonts in Motif only work with UTF-8 endoding. In my opinon the program should only use UTF-8 internally, and do the conversion on loading and saving to/from other encodings, if necessary. This is what I did in my other Motif programs and it significanlty reduced code complexity. But it is probably more difficult for xnedit, if it wishes to keep compatibility with older platforms, which do not support XFT.
Thank your very much, this version compiles. Maybe a new version of the source distribution jpeg2pdf_1.1_src.zip should be created, in order to avoid the confusion. Or remove the one that does not compile, so one goes straight to the "code" area. And thanks for creating such a useful tool.
Last version does not compile on Linux (SUSE Leap 15, 64 bits, gcc 7.3.1), it gives the following errors: testMain.c: In function ‘main’: testMain.c:474:25: error: ‘filesarray’ undeclared (first use in this function); did you mean ‘filename’? findMaximumDimensions(filesarray, globlen, pageOrientation==Portrait || pageOrientation==Landscape, &pageWidth, &pageHeight); ^~~~~~~~~~ filename testMain.c:474:25: note: each undeclared identifier is reported only once for each function it appears in testMain.c:491:4:...
Thanks!
I think nowadays Ctrl+wheel - zoom in/out is more standard action than page up/down. I discovered that Firefox uses Alt+wheel for back/forth for navigating pages. So that could be roughly equivalent to page up/down. You could make Ctrl+wheel - zoom in/out, and Alt+wheel - page up/down; maybe with options to reverse the setting, if user is locked in one type of use. From the point of view of user interfaces, following the rule of least surprise, it is better to use the most common action for each...
Ctrl+wheel mouse up/down has become a very common user interace to change view/font size. It works in Open Office, MS Office, Firefox, Kate text editor, Konsole... Xnedit already has a nice capability to change main window text font on the fly, without closing the program. So adding the capacity to increase/decrease font size on mouse button 4/5 would help a lot to many elderly users or users with 4K monitors with poor dpi settings. Sometimes it also helps to see the structure of the program, if...
Font selector preview is nice, but it only displays one font variant. As you select the font, you can "Fill Highlight Fonts from Primary", but there is no preview of how that would look. For decent programming editor font choice, the highlight fonts must also look nice and balaced. Many fonts look nice in the base version, but horrible in bold or italic. So some form of preview of all font variants would be good, either in exisiting font selector preview, or provide separate font preview for each...
There is a small bug in font selector. Default font is selected automatically as you press "Browse..." buton and font selector opens, but the font point size is not, program always defaults to 10 points.
Thanks, it is working now.
The current snapshot crashes if I try to load a .c file, for example calltips.c from the source directory. The offending line is in textDisp.c in XftFont FindFont(NFont f, FcChar32 c) { if(c == 0) { return f->fonts->font; } /* make sure the char is not in the fail list, because we don't * want to retry font lookups */ NCharSetList *fail = f->fail; <<<<< Crash It was working on a snapshot from two days ago. My system: SUSE Linux Leap 15, 64 bit, latest Motif from sourceforge
Fantastic, it works! I can work so much faster now.
I did some experiments with rigth to left in my software with Farsi (Persian) in Motif. XmLabel.layoutDirection: RIGHT_TO_LEFT XmToggleButton.layoutDirection: RIGHT_TO_LEFT XmPushButton.layoutDirection: RIGHT_TO_LEFT XmCascadeButton.layoutDirection: RIGHT_TO_LEFT XmOptionMenu.layoutDirection: RIGHT_TO_LEFT XmSelectionBox.layoutDirection: RIGHT_TO_LEFT XmScale.layoutDirection: RIGHT_TO_LEFT The Farsi text was displayed correctly, but if I used ASCII characters within the same text (a necessity for...
I did some experiments with rigth to left in my software with Farsi (Persian) in Motif. XmLabel.layoutDirection: RIGHT_TO_LEFT XmToggleButton.layoutDirection: RIGHT_TO_LEFT XmPushButton.layoutDirection: RIGHT_TO_LEFT XmCascadeButton.layoutDirection: RIGHT_TO_LEFT XmOptionMenu.layoutDirection: RIGHT_TO_LEFT XmSelectionBox.layoutDirection: RIGHT_TO_LEFT XmScale.layoutDirection: RIGHT_TO_LEFT The Farsi text was displayed correctly, but if I used ASCII characters within the same text (a necessity for...
I did some experiments with rigth to left in my software with Farsi (Persian) in Motif. XmLabel.layoutDirection: RIGHT_TO_LEFT XmToggleButton.layoutDirection: RIGHT_TO_LEFT XmPushButton.layoutDirection: RIGHT_TO_LEFT XmCascadeButton.layoutDirection: RIGHT_TO_LEFT XmOptionMenu.layoutDirection: RIGHT_TO_LEFT XmSelectionBox.layoutDirection: RIGHT_TO_LEFT *XmScale.layoutDirection: RIGHT_TO_LEFT The Farsi text was displayed correctly, but if I used ASCII characters within the same text (a necessity for...
It is precisely the middle click that is a big time saver for me when doing translations by google translate. I know the selections are different and have some grey hair from Unix cut&paste in the graphical programs I develop. I just whish you were aware of the problem, fix at as you see fit.
Besides programming, I use nedit for translations in many languages. Cut and paste with Ctrl+C Ctrl+V works correctly with UTF-8, but if I use middle mouse button, I get expanded numeric code instead of the pasted character(s). Thanks for continuing development on Motif, it shows that latest Motif has the functionality to make nedit useful in the next decade!
Besides programming, I use nedit for translations in many languages. Cut and paste with Ctrl+VC Ctrl+V works correctly with UTF-8, but if I use middle mouse button, I get expanded numeric code instead of the pasted character(s). Thanks for continuing development on Motif, it shows that latest Motif has the functionality to make nedit useful in the next decade!
Personally, I am OK with the name change, since the extra functionality like UTF8 and AA fonts was often met with hostilty by users of defunct platforms. I remember such discussions of SGI users on nekochan (now also closed). Realistically speaking, there was not much development going on nedit for years, and I expect more new development on the Qt port (nedit-ng) and on xnedit.
Besides programming, I use nedit for translations in many languages. Cut and paste with Ctrl+V, Ctrl+V works correctly with UTF-8, but if I use middle mouse button, I get expanded numeric code instead of the pasted character(s). Thanks for continuing development on Motif, it shows that latest Motif has the functionality to make nedit useful in the next decade!
In case someone did not find it already, there is a new fork of nedit, still based on Motif, which supports antialiased fonts and UTF-8 https://sourceforge.net/projects/xnedit/ I have compiled it on Linux, it works out of the box, displays all fonts. It looks like we will have two modern nedits, one based on Qt and another on latest Motif.
Thank you Graham, will be fixed.
Scroollto feature is also useful when HTML contents is refreshed due to recalculation....
If you need to display UTF8 and antialiased fonts from HTML in your Motif application,...