Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: MikeLockmoore on March 31, 2012, 06:37:09 PM
-
Fellow Fluff-heads ( :o): I have made many small changes to Fluff to address several of the bugs and shortcomings reported over the last year or so. This includes file renaming issues, windows not resizing properly, flicker on filesystem updates, and inability to use the file associations dialog boxes to configure associations for generic files (i.e. files not recognized as some more specific type). Thanks to coreplayer2, floppy, and others for reporting issues.
The attached source code archive includes a make file to build the executable, create a new fluff.tcz extension, and, if you'd like, install the extension persistently ("make install") in your TCE directory for the "onboot" mode. Or if you already have an onboot installation of Fluff, you can use the make file to update your copy ("make update"). To use the makefile, you will need the compiletc.tcz and squashfs-tools-4.x extensions and extract the archive file someplace, perhaps like this:
tar -xzf fluff_1_0_3_src.tar.gz
If you use make with no target, ("make"), only the Fluff executable "fluff" is created. You can run this local executable from the build directory to test it without disturbing a current installation.
If you "make package", the fluff.tcz extension package is created. Once this is done, you could use AppBrowser or the command line "tce-load -ic fluff.tcz" to do a local installation. NOTE: this is a temporary, non-persistent type of installation!
As stated above, "make install" will do a persistent, on-boot type of installation. NOTE: the TCE directory is identified in different ways in 3.x and 4.x versions of Core/Tiny Core, so if you are building for a 3.x version, un-comment the alternative TCEDIR environment variable definition and comment out the 4.x version.
If you have any issues or bugs to report in this new version 1.0.3, or any later ones in this beta series, please post them here. Once this new version is in good shape, I will release it to be posted in the official Tiny Core repository as version 1.1. If needed, there could be additional beta versions between this 1.0.3 and the formal release of version 1.1.
I hope to get the Fluff source code up on Github someday. But for now, this forum will be the source code repository. If you can't do a build, but you really want to beta test this new version, PM me and I will work out something to make it easier for you.
If you have ideas for new features or significant changes, please post those comments in this separate thread: http://forum.tinycorelinux.net/index.php/topic,9517.0.html (http://forum.tinycorelinux.net/index.php/topic,9517.0.html). I will work on some of those ideas as I have time. ;)
I hope this new version works better for all of you!
-
Cool thanks will check it out :)
-
Already checking it out. :)
Very cool. Thank you.
The initial DirTreeWide value of 131 seems a bit narrow, but seriously - if that's the biggest issue, I'd say you pretty well nailed it. :)
-
:-[ I found and hopefully fixed a significant bug in the file type identification function. Please discontinue using the 1.0.3 version and test with 1.0.4, attached bellow. Please report any other bugs and issues. Thanks.
-
use tc's editor open the "fluff.cpp" file will be changed.
in vi
else if (ans == 1) {
if (restore_mode) {
FileMenuCB((Fl_Widget*)MainWnd_p->list_p, (void*)MI_RESTORE);
}
else {
wait_cursor();
int t = 0;
- fluff.cpp 3854/6551 58%
change to
else if (ans == 1) {
if (restore_mode) {
get*)MainWnd_p->list_p, (void*)MI_RESTORE);
}
else {
wait_cursor();
int t = 0;
and while compile 1.0.0 and 1.0.3's fluff.cpp are also easy changed by self in the line 38xx .
-
I use fltk-1.3-dev to compile unicode version
tc@box:~/fluff1.0.4$ make
g++ "-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti" `fltk-config --cxxflags` -Wall -c fluff.cpp
gcc `fltk-config --use-images --ldflags` -lfltk_images -lm fluff.o -o fluff
fluff.o: In function `btnbar_help_cb()':
fluff.cpp:(.text+0x426): undefined reference to `Fl_Help_Dialog::textsize(int)'
fluff.o: In function `Fl_DND_Box::callback_deferred(void*)':
fluff.cpp:(.text+0x563): undefined reference to `Fl_Widget::do_callback(Fl_Widget*, void*)'
fluff.o: In function `File_Detail_List_Browser::draw()':
fluff.cpp:(.text+0x704): undefined reference to `fl_graphics_driver'
fluff.cpp:(.text+0x74b): undefined reference to `fl_graphics_driver'
fluff.o: In function `Fl_DND_Box::handle(int)':
fluff.cpp:(.text+0x882): undefined reference to `Fl_Widget::do_callback(Fl_Widget*, void*)'
fluff.o: In function `wait_cursor()':
fluff.cpp:(.text+0x91b): undefined reference to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)'
fluff.o: In function `normal_cursor()':
fluff.cpp:(.text+0x942): undefined reference to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)'
fluff.o: In function `Fluff_Window::handle(int)':
fluff.cpp:(.text+0xa508): undefined reference to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)'
fluff.cpp:(.text+0xa638): undefined reference to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)'
fluff.o: In function `File_Detail_List_Browser::handle(int)':
fluff.cpp:(.text+0xa7cc): undefined reference to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)'
fluff.o:fluff.cpp:(.text+0xa8dc): more undefined references to `fl_cursor(Fl_Cursor, unsigned int, unsigned int)' follow
fluff.o: In function `File_Detail_List_Browser::handle(int)':
fluff.cpp:(.text+0xaa3a): undefined reference to `Fl_Widget::do_callback(Fl_Widget*, void*)'
fluff.o: In function `faded(unsigned int&, float)':
fluff.cpp:(.text+0xac3c): undefined reference to `Fl::get_color(unsigned int, unsigned char&, unsigned char&, unsigned char&)'
fluff.o: In function `configure_colors()':
fluff.cpp:(.text+0xad06): undefined reference to `Fl::get_color(unsigned int, unsigned char&, unsigned char&, unsigned char&)'
fluff.cpp:(.text+0xad1f): undefined reference to `Fl::set_color(unsigned int, unsigned char, unsigned char, unsigned char)'
fluff.cpp:(.text+0xad3b): undefined reference to `Fl::get_color(unsigned int, unsigned char&, unsigned char&, unsigned char&)'
fluff.cpp:(.text+0xad54): undefined reference to `Fl::set_color(unsigned int, unsigned char, unsigned char, unsigned char)'
fluff.cpp:(.text+0xad68): undefined reference to `Fl::get_color(unsigned int, unsigned char&, unsigned char&, unsigned char&)'
fluff.cpp:(.text+0xad81): undefined reference to `Fl::set_color(unsigned int, unsigned char, unsigned char, unsigned char)'
fluff.cpp:(.text+0xad9d): undefined reference to `Fl::get_color(unsigned int, unsigned char&, unsigned char&, unsigned char&)'
fluff.cpp:(.text+0xadb6): undefined reference to `Fl::set_color(unsigned int, unsigned char, unsigned char, unsigned char)'
fluff.o: In function `fl_color(int)':
fluff.cpp:(.text._Z8fl_colori[fl_color(int)]+0x7): undefined reference to `fl_graphics_driver'
fluff.o:(.rodata._ZTV16Dir_Tree_Browser[vtable for Dir_Tree_Browser]+0x3c): undefined reference to `Fl_Browser::item_last() const'
fluff.o:(.rodata._ZTV16Dir_Tree_Browser[vtable for Dir_Tree_Browser]+0x50): undefined reference to `Fl_Browser::item_text(void*) const'
fluff.o:(.rodata._ZTV24File_Detail_List_Browser[vtable for File_Detail_List_Browser]+0x3c): undefined reference to `Fl_Browser::item_last() const'
fluff.o:(.rodata._ZTV24File_Detail_List_Browser[vtable for File_Detail_List_Browser]+0x50): undefined reference to `Fl_Browser::item_text(void*) const'
fluff.o:(.rodata._ZTV17Fl_Select_Browser[vtable for Fl_Select_Browser]+0x3c): undefined reference to `Fl_Browser::item_last() const'
fluff.o:(.rodata._ZTV17Fl_Select_Browser[vtable for Fl_Select_Browser]+0x50): undefined reference to `Fl_Browser::item_text(void*) const'
fluff.o:(.rodata._ZTV16Fl_Multi_Browser[vtable for Fl_Multi_Browser]+0x3c): undefined reference to `Fl_Browser::item_last() const'
fluff.o:(.rodata._ZTV16Fl_Multi_Browser[vtable for Fl_Multi_Browser]+0x50): undefined reference to `Fl_Browser::item_text(void*) const'
fluff.o:(.rodata._ZTV15Fl_Hold_Browser[vtable for Fl_Hold_Browser]+0x3c): undefined reference to `Fl_Browser::item_last() const'
fluff.o:(.rodata._ZTV15Fl_Hold_Browser[vtable for Fl_Hold_Browser]+0x50): undefined reference to `Fl_Browser::item_text(void*) const'
collect2: ld returned 1 exit status
make: *** [all] Error 1
tc@box:~/fluff1.0.4$ fltk-config --compile fluff.cpp
g++ -I/usr/local/include -march=i486 -mtune=i686 -Os -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'fluff' 'fluff.cpp' /usr/local/lib/libfltk.a -lXext -lpthread -ldl -lm -lX11
/tmp/ccSVVDTT.o: In function `btnbar_help_cb()':
fluff.cpp:(.text+0x405): undefined reference to `Fl_Help_Dialog::Fl_Help_Dialog()'
fluff.cpp:(.text+0x41c): undefined reference to `Fl_Help_Dialog::load(char const*)'
fluff.cpp:(.text+0x426): undefined reference to `Fl_Help_Dialog::textsize(int)'
fluff.cpp:(.text+0x42e): undefined reference to `Fl_Help_Dialog::show()'
fluff.cpp:(.text+0x448): undefined reference to `Fl_Help_Dialog::visible()'
fluff.cpp:(.text+0x45e): undefined reference to `Fl_Help_Dialog::~Fl_Help_Dialog()'
fluff.cpp:(.text+0x474): undefined reference to `Fl_Help_Dialog::~Fl_Help_Dialog()'
collect2: ld returned 1 exit status
tc@box:~/fluff1.0.4$
and vi fluff.cpp
void btnbar_help_cb(void)
{
// Fl_Help_Dialog hd;
// IgnoreNextKey = 1;
// hd.load("/usr/local/share/doc/fluff/fluff_help.htm");
// hd.textsize(14);
// hd.show();
// while (hd.visible()) {
// Fl::wait(1);
// }
}
I fluff.cpp [Modified] 3932/6551 60%
#include "FontSetup.h"
I fluff.cpp [Modified] 78/6551 1%
then
tc@box:~/fluff1.0.4$ fltk-config --compile fluff.cpp
g++ -I/usr/local/include -march=i486 -mtune=i686 -Os -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'fluff' 'fluff.cpp' /usr/local/lib/libfltk.a -lXext -lpthread -ldl -lm -lX11
tc@box:~/fluff1.0.4$
the "fluff" exefile is 573.40KB
tc@box:~/fluff1.0.4$ strip fluff
the "fluff" exefile change to 480.52KB
why can use "fltk-cofig --compile fluff.cpp " and can not use "make" ?
-
the "fluff" exefile is 573.40KB
tc@box:~/fluff1.0.4$ strip fluff
the "fluff" exefile change to 480.52KB
..and "strip --strip-all fluff"?
-
Hi quanpin. I see that you want a Unicode Fluff. I did not make it Unicode because Tiny Core base does not come with Unicode support.
Perhaps you know FLTK 1.3 is not a standard part of Tiny Core Linux. I see your second post includes a compile+link command referencing /usr/local/lib/libfltk.a. This means that gcc will _statically_ link copies of the FLTK 1.3 functions into the Fluff executable, which makes it much bigger. The non-unicode Fluff _dynamically_ links to FLTK version 1.1, so its executable is much smaller (~150 kilobytes).
I don't understand your first post. ??? Why did you edit it that way? The new code looks corrupted. I think "get*)MainWnd_p->list_p, (void*)MI_RESTORE);" won't compile.
I will not release a Unicode version in the near future, but perhaps I can make the source code more compatible with the Unicode version of FLTK if I understand the problems better.
--
Mike
-
I'm testing fluff 1.0.4 and I don't see problems, thanks a lot Mike.
- files with extension MPG should be threted the same as mpg.
- link creation is missing.
- Is not possible to change the curson when the mouse is on the line which divides the 2 panels?
- when we go deep into directories they are no more visible in the left panel so the panel could be auto-enlarged
-
Thanks, the blank window appearance during resizing appears to be fixed :)
The achilles heel with all file managers it seems is the ability to know which app to open a particular file with or how easy the file manager makes setting the default app for these various file types. will advise..
-
I don't understand how mp4 video files are so difficult to handle, I find I have to go through the whole process of "Open With" etc etc each and every time I want to play a video, even the same video. It's likely I have not figured out yet how to set and configure default programs to open specific files, but for sure it's not intuitive.
The other issue of scrolling to find your place after a file copy or move persists in v1.04.
How about an example. Lets say we have 1000 files in a directory in the right pane with 200 files starting with the litter S, lets say we want to copy specific files to various other locations via drag and drop to a directory in the left pane which obviously can't be performed in a single operation. we scroll down the list of files in the right pane until we find one or two files with similar names beginning with S to move, we select them and drag them to there new location and select move from the menu. Up to this point all is good, however this is where the issue occurs, because immediately after the move operation the right window items are re-sorted in alphabetical order now starting with files beginning with A, in effect we have lost our place within the files names beginning with S, more importantly we have lost our price location where the previously moved files were found. Yet more similarly name files (beginning with S which where previously located near the last files moved) still require moving to another location, since we we have lost our place after the reshuffle we are forced to search via scrolling through 1000 files to find files beginning with S then further search within these files names to find our previous location. We are finally back to our previous location and can copy the next file(s). and so on...
If this wasn't frustrating enough, try this whilst the left pane of expanded directories are behaving similarly..! Now we are totally lost, we don't know if we're looking at the source or the destination. For many tasks whilst working this behavior is very frustrating, to be constantly searching for your last location in the list/column so you can press on..
To sum up the issue is the highlighting of the first file in a selected column after a re-sort. this effectively looses your place in the column of listed files.
Please don't misunderstand I luv Fluff :)
-
coreplayer2: Thanks for taking the time to retest and write a detailed description. I can see that the current behavior for drag-and-drop is not nice when there is a large set of files. I'll try to make Fluff work better by trying to have Fluff remember the scroll location within the original set of files, whether some of the files have moved or not.
To set up a new default app for a certain type of file like .mp4, select an example then invoke the properties window (Props button or right-click on the file and select Properites). In the Properties window, click on the Type button. You will be asked for a short descriptive name (like "video") of the file type. After you enter one, the "Manage File Types and Hints" dialog box opens.
If the file you selected ends with a dot - something naming pattern, the "Filename extension" filetype Hint method will be pre-selected. This should work OK if your files will be named like this consistently. The hint method is how Fluff distinguishes each file type and so it can offer suitable default applications for it. If you know of a special byte sequence in the early part of the file that will be an unambigously "fingerprint" the filetype (like "BM" in Windows Bitmap files), then you can change the Hint method. You can also define additional hint methods, for example, if the filetype extensions can be spelled or capitalized different ways (.mp4, .MP4, etc.).
In the "Manage File Types and Hints" you can click on "Associated apps..." button to open the "Manage Associations" dialog box, which you use to define the apps that will be the default ones. The first listed app will be the one that is used if you double-click on the file, and the first two apps are the ones that appear in the button bar and right-click menu. Additional apps can be accessed with the "Open With" command, as you seem to be using now.
jls: Thanks for testing and comments. As I said to coreplayer2, for .MPG and .mpg... for now you can set up a second hint method with the alternate capitalization. I'll think about whether to make the hint system ignore capitalization. I will try to get the mouse cursor to change when over the separation between left and right panes. (I thougth I had that working before! ???) I think auto-enlarging the left pane will not be wanted by everyone... let me think about it. Maybe these won't make the version 1.1. Link creation is a good idea but probably in later version after 1.1.
-
If I use e17 DM when I minimize fluff it closes instead of minimizing
-
jls: That's weird. ???
If you start Fluff from a command prompt, then minimize, is there any error message or other output that might provide a clue as to why it would close in e17? If not, I'll have to think about why it might do that. Thanks for reporting it.
-
no error message, no output, and nothing also in dmesg
-
jls: maybe a segfault. I don't plan to install Enlightenment anytime soon, but would be willing to try to make a fix if you can help me isolate the area of Fluff that is not working properly and retest the possible fix. Here are two things to try first:
1) Uncomment some of the printf() statements, rebuild, and run from the the command-line, especially line 3566 at the top of the main window event handler and maybe insert at line 6550 a new printf() before the return statement:
printf("\nFluff exited normally.\n");
With this we can compare the event sequence sent to Fluff by FLWM versus the sequence sent by Enlightenment during the window minimize action.
2) Make a "debug" build Fluff and run it in gdb debugger. gdb will tell us if it is exiting normally or because of a segfault or some other exception. If it does crash, use the 'bt' command in gdb to print a back-trace and send a copy to me so I can see the execution path that lead to the crash.
-
I did what u wanted but it looks like there is no crash, anyway I've attached to this post the backtrace.
I've splitted the log in 2 parts because the file was too big as attachment
-
I made the tests with fluff 1.0.3
-
Thanks jls. I agree is does not look like a crash. I will need to compare the GUI event codes and their sequence in your log to the same scenario in FLWM and see how they differ. Am I correct in assuming you clicked on the minimize window control just before Fluff exits?
-
Am I correct in assuming you clicked on the minimize window control just before Fluff exits?
yes, you are correct, if I'm not wrong fluff exits also if I change desktop
-
jls: try to comment out the "Running = 0" statement at about line number 3677 so it looks like this:
case FL_HIDE:
//Running = 0;
return 1;
Then recompile and try it in Enlightenment.
I'm not seeing the FL_HIDE event appear when using Fluff in FLWM, but that event is in the log you posted. I'm don't remember right now why I have Fluff exiting when FL_Hide appears, but I'm sure I had a reason in the past.
Assuming this fixes the problem for you and it also seems to work in FLWM now (why not before?) I'll put this fix into the official Fluff release.
EDIT: If Fluff does not minimize after the change, also try to comment out all three lines shown above.
-
no change, also commenting all the 3 lines.
I was wrong, fluff doesn't closes if I change desktop, only if I minimize it.
I found another bug:
if I open a generic file, it opens with vi, but when I close vi it opens it again, then I close and it's ok.
I mean it opens vi twice
-
jls: I found a fix for the minimize issue, but could not reproduce your double instance of vi bug. I tested it by moving my current .fluff.conf file to a new name so the when Fluff starts it uses default parameters. I used the edit command on a text file. It opened vi and I could use the :q command to quit it, and it closed without opening a second time. I don't know why you have two instances. Maybe check your .fluff.conf file for multiple entries in the associated app settings?
all: The attached source package for version 1.0.5 has the following fixes/changes in response to recent issues:
1) After a file move or copy, the file details (right side) window will remember your scroll position so you can continue from the same location. (Thanks to coreplayer2 for suggestions.)
2) When the mouse pointer moves over the separation between left (tree) and right (list) panes, the cursor shape changes to a double arrow (<-->) to help users notice that the panes can be resized. (Thanks to jls_legalize for the suggestion.)
3) When the user clicks on the minimize button, Fluff only minimizes, not exits (as it does in e17 and perhaps other window manager/desktop besides FLWM). (Thanks to jls_legalize for the bug report)
4) "Fluff" or "Fluff File Manager" is now in the window title instead of the generic "FileMgr" - isn't branding key? ::)
If you can, please download this latest version, build, test, and report any further issues here. Thanks everyone for your interest and feedback!
-
ok mike
now on minimizing fluff doesn't closes.
The double opening happens when double clicking on a file, not if I press enter.
-
jls: I understand the problem better now but don't have an acceptable fix. FLTK in my opinion ( >:() has a bug, because a parent window will often receive an event that should have been consumed by a child window that is closing. For example, when you close the vi session with :q[enter] or even when the application presents a FLTK message box that you close with the enter key. The parent window gets the Fl_Enter keypress event, although it logically was intended to go to the child window (e.g. the vi session in a separate terminal window). Who wants the parent window to _also_ respond to the same key press? ::) To make matters works, e17 and FLWM seem to be somewhat different in the event sequence and other details. :P
I have a hacky way of ignoring extra key press events from the FLTK warning/info message boxes I use in Fluff, but so far I don't have a good way to manage the enter key event that comes from a file-associated application. There are times you would like to select a file and press [enter] in Fluff, so [enter] is sometimes valid, and so I can't just ignore it all the time. I will try to keep working on a good fix.
Maybe the FLTK dev's forum has some ideas on this. It seems like a huge quirk if not outright bug, and it's hard for me to believe an acceptable fix or way to manage this behavior is not yet known.
-
Hi MikeLockmoore
a parent window will often receive an event that should have been consumed by a child window that is closing.
I guess you don't have access to the do-not-propagate-mask?
-
Hi Rich. Is that is something that comes from X? I'm far from an expert in X fundamentals. :(
The issue jls has posted happens when we use aterm in a child process to execute vi editor, and the final enter key press that closes vi is getting replicated up to the parent (Fluff). Where and how does one set a mask for that? Fluff doesn't always directly create the child window. For the aterm window, it's invoked through a call like system("aterm -e vi ..."). For the little message boxes used in Fluff, its called through the FLTK functions like fl_message("..."), so I don't have direct access to an event mask then either, as far as I know. But I'm willing to learn more, if you have a good reference or can 'splain a thing or two here. ;)
-
Hi MikeLockmoore
Although far from being an expert, I have been playing around with some X programming. You can use the
do-not-propagate-mask to prevent mouse clicks or key presses from propagating up to that windows parent.
XSetWindowAttributes xswa;
xswa.do_not_propagate_mask=ButtonPressMask | KeyPressMask;
XChangeWindowAttributes(display, window, CWDontPropagate, &xswa);
http://tronche.com/gui/x/xlib/window/XChangeWindowAttributes.html
-
Hi MikeLockmoore
This may also be of some use:
http://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html
Assuming you have access to the event loop and the window IDs of the windows you create for Fluff, you might
be able to filter out events that did not originate in one of your windows. Unfortunately, the structure lists three
different window IDs:
Window window; /* ``event'' window it is reported relative to */
Window root; /* root window that the event occurred on */
Window subwindow; /* child window */so you would need to figure out which field is the relevant one.
-
Thanks Rich. I'll see if I can make some use of that info.
-
Hi MikeLockmoore
Well, I got curious, so I decided to examine the values returned by those three Window fields.
The window field is the ID of the window where the event occurred.
The root field is the ID of the root window, which is the parent of all windows on the system.
The subwindow field was always zero.
-
Rich: Thanks for the additional info. I don't think FLTK makes it easy to look at the raw X event info, but if I need to, perhaps I can figure out a way. Based on some feedback on the FLTK developer's forum, I may be able to re-do some event criteria in Fluff so it avoids the little problems jls has been helping to point out.
I think one key (sorry about the pun ::)) observation is that FLTK, like many (all?) GUI toolkits sends both a KEY-DOWN (pressing) and KEY-UP (releasing) events. The vi session in aterm in the situation that jls posted closes on the key-down event in the aterm window. Then, when the user releases the key, the focus is probably back on Fluff, so the key-up is sent there (aterm no longer exists). But I've coded most of the keyboard shortcuts to act on key-up. So if I can switch things to mostly reacting on key-down, it may work out better. I don't know yet if there will be many other side effects, but there could be some. Hopefully fewer and easier to manage overall, and will let me clean up some uglier parts of the Fluff code. :)
-
Sorry for the long absence. :-[
I have reworked the keyboard handling stuff in Fluff to take action on key-down events, which seems to eliminate (most of?) the weirdness we had before. This seems to be fundamentally better, and I was able to delete all of the "Ignore next key" stuff that I kludged in the earlier versions.
So I think this new version 1.0.6 will be better-behaved, especially in relation to keyboard use, but please be aware that some keyboard behavior may be a little different than you are used to if you are a habitual Fluff user.
jls: I did a quick test in E17 (Elightenment) and I think Fluff is now well-behaved.
all: If you have any feedback on this new version, please post! Thanks for your patience. -Mike
-
Thanks, we really appreciate all your efforts working out the gremlins and enhancements to our favorite file manager
;)
-
the explore button opens another instance positioned in the root of the file system.
Thanx for the archive button.
If I press the TCE button I see: no TCE drive defined...
-
jls: thanks again for more testing and feedback. New version 1.0.7 handles the TCE directory better and should find the TCE directory at the place pointed to by /opt/.tcedir (for Tiny Core versions 3.x), or at /etc/sysconfig/tcedir/, or at /tmp/tce. If all of those fail, then you might see the message about setting up a TCE directory.
I also changed the way a terminal is opened. The command is now "cd [directory]; aterm &". I hope this works better for you. Please let me know if it works. If not, perhaps I can set up a way to have a custom terminal command string read from the .fluff.conf file.
-
Thanks for the update.
The TCE button now works, but the explore no, it still opens the root dir.
Maybe better to change aterm to xterm since xterm it's just a link to aterm and if one use another terminal I think it should change the xterm link.
-
jls: Could you try to modify your copy of the fluff.cpp to call xterm and let me know if it can open a terminal in the appropriate directory? The line numbers to change are 588, 589, 596, 5030, 5328, and 6359. It works for me either way.
-
Yikes, someone needs to #define "xterm" ;)
-
Yikes, someone needs to #define "xterm"
The proper way would be to use/check the environment variables, no? And as I mentioned, maybe I can set up a .conf file option to provide the terminal startup command of your choice.
But first I was hoping we could try a few hacks to see if we can get the terminal opening in the currently-viewed directory in e17. If anyone could explain why it seems to be always defaulting to the root directory, I'd like to hear it!
-
Hi MikeLockmoore
If the current working directory of fluff is root while it's running, and the cd command in "cd [directory]; aterm &"
fails, that will cause that behavior.
[EDIT:] Sorry, that's wrong, I didn't pay close enough attention.
-
Oh, just commented on having to change it in six places instead of one ;)
-
I was sayng hat the explore button always opens the root dir, while the terminal works, opening the current dir
-
jls: ? I did not understand your comment. Maybe I still don't understand. Is the "explore" button doing something wrong? If you think so, it would help me if you could provide some more explanation. Perhaps a screen capture would help too.
Curaga: Yes, perhaps, but several places have the aterm/xterm as part of a longer literal string, so factoring out the "aterm"-only part to a #define would require inserting it into various other stings, so it's not a clear advantage here. I do use #defines in other situations of course.
-
Hi MikeLockmoore
The proper way would be to use/check the environment variables, no?
That's what I would have thought, however, the env command lists:
COLORTERM=rxvt
TERM=rxvtby default instead of aterm. I see this under TC3.4 and TC4.1 even though rxvt is not installed.
-
@Mike
Prepare to be initiated into darkest C secret #4587, the automatic concat of strings ;)
#define TERM "xterm"
system(TERM " -e nano");
This would preprocess to
system("xterm" " -e nano");
Which would then compile as
system("xterm -e nano")
-
Hi curaga. I know that one! I use it. I don't think it's too helpful here... I'd like to make things flexible for users, so the terminal to use should probably be something configurable in the .conf file. That way, if the user has installed an alternate terminal emulator and prefers using it, she/he can configure Fluff to use it too. Maybe need a way to pass the local directory to start in to the configurable terminal command too. I make no promise on when I might implement this kind of configurability. :P
-
To compile fluff_1.0.7 in TC-5.0 Alpha, a minor change to the makefile and an additional dependency is needed.
First, " fltk-1.1.10-dev.tcz " is required to compile
additionally the following change to the makefile. Seems like a change to the linker in g++ ??
linking libstdc++.so.0.6 to the command line in fluff's makefile
from this
all: ${PROG}.cpp
g++ ${CXXFLAGS} `fltk-config --cxxflags` -Wall -c ${PROG}.cpp
gcc `fltk-config --use-images --ldflags` -lfltk_images -lm ${PROG}.o -o ${PROG}
strip ${PROG}
echo `ls -l fluff`
to this
all: ${PROG}.cpp
g++ ${CXXFLAGS} `fltk-config --cxxflags` -Wall -c ${PROG}.cpp
gcc `fltk-config --use-images --ldflags` -lfltk_images -lstdc++ -lm ${PROG}.o -o ${PROG}
strip ${PROG}
echo `ls -l fluff`
fluff now compiles in TC-5.0-Alpha and runs great (despite a couple of additional minor warnings)
-
You shouldn't use gcc to link c++. It will crash and burn.
-
Thank you for the heads up, that is as I understand also. but that was the resolution recommended by the compiler error message. So have pm'd MikeLockmoore
-
Thanks coreplayer2 for the build suggestions. I would like to set up an installation of TC 5.0 Alpha on a USB stick and do some tests and at least minor updates to my FLTK app packages including Fluff over the next several weeks. I won't have much time in the next week or so however. :(
My new main Linux laptop is a < 1 year-old Sandy-Bridge-class dual core Pentium machine from ASUS, which came with Windows 7 and I think uses UEFI for the boot loader. Any advice on how to set up a bootable TC 5.0 USB stick to work with this? Or anybody? :) I've hesitated because TC 4.7 has been out so long and now TC 5.0 is coming and I was not sure how well UEFI is supported.
Currently, I have Xubuntu 12.04 installed on the hard drive along with a boot option for Windows 7 (which I only use to grab pictures from an SD memory card because that drive is completely dead in Xubuntu). But if I get back to using TC again regularly, I would do a better job of keeping the apps maintained, maybe even improved. Later, after TC 5.0 is officially released, I would like to do a full frugal or similar install on my hard drive.
-
.. and I think uses UEFI for the boot loader. Any advice on how to set up a bootable TC 5.0 USB stick to work with this? Or anybody? :) I've hesitated because TC 4.7 has been out so long and now TC 5.0 is coming and I was not sure how well UEFI is supported.
There's a whole thread on the efi/uefi saga:
http://forum.tinycorelinux.net/index.php/topic,13445.msg89096.html#msg89096
In short tc-5.x (and tc-4.x with a recompiled kernel) will boot from a usb stick on both mac (efi) and pc (uefi) and I've tested tc-5.x on both.
BTW - a couple of your fltk apps need recompiling for the updated libpng in tc-5.x ;)
-
Thanks Juanito. I think I've read some of that thread before, but I need to do so more carefully so I can get a good working installation. I want to make sure my stuff compiles and runs properly with the new TC series.
-
tryng to build in 5.x
tce-load -wil fltk-1.1.10-dev.tcz
Downloading: fltk-1.1.10-dev.tcz
Connecting to repo.tinycorelinux.net (89.22.99.37:80)
fltk-1.1.10-dev.tcz 100% |*******************************| 540k 0:00:00 ETA
fltk-1.1.10-dev.tcz: OK
jls@pc2:~$ make package
g++ "-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti" `fltk-config --cxxflags` -Wall -c fluff.cpp
fluff.cpp:580:1: warning: narrowing conversion of '255' from 'int' to 'char' inside { } is ill-formed in C++11 [-Wnarrowing]
fluff.cpp:580:1: warning: narrowing conversion of '216' from 'int' to 'char' inside { } is ill-formed in C++11 [-Wnarrowing]
gcc `fltk-config --use-images --ldflags` -lfltk_images -lm fluff.o -o fluff
/usr/local/bin/ld: fluff.o: undefined reference to symbol '_Znaj@@GLIBCXX_3.4'
/usr/local/bin/ld: note: '_Znaj@@GLIBCXX_3.4' is defined in DSO /usr/lib/libstdc++.so.6 so try adding it to the linker command line
/usr/lib/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make: *** [all] Error 1
-
That's a bug in fluff's Makefile, already been mentioned. It tries to use a C compiler for C++ code.
-
Yeah, I guess gcc would link the C++ stuff in my earlier Tiny Core installations. Just change gcc to g++ for the link step in the makefile, if you have not yet.
I've tried again to get TC 5.0 running on my current laptop without success, probably because this laptop has UEFI boot firmware (but not SecureBoot, thank goodness).
I have tried a few different ways to do a USB stick installation and a frugal hard disk installation and so far nothing works. Perhaps I will post the specifics of some of my recent attempts to see if anyone can offer some suggestions.
-
Just to get tc booting, have you tried setting legacy mode (or legacy USB, or...) within the BIOS. All UEFI BIOS capable pc's should come with a legacy option.
Once booted, you should be able to install grub v2 to your USB drive using the appropriate tc-5.x extension.
As a precautionary measure, AIUI it's not advisable to boot to your existing install while in legacy mode. At least make a backup
Good luck,
I'm still using the re-compiled latest version from this thread in tc-5.x, maybe I'll take a look at the makefile..