0.4.0 RC 2 Test builds available - Page 2

JSWolf · 08-06-2011, 01:09 PM

I do have one issue with the installer. It installs the desktop icon in the wrong account. It install it in Public instead of the account I am currently using. I don't put any desktop icons in public. Can this please be fixed even if it's just a requester asking where to put the desktop icon? Assuming where to put it is not a good idea as not everyone does things the same way.

user_none · 08-06-2011, 03:02 PM

Quote:

Originally Posted by JSWolf

I do have one issue with the installer. It installs the desktop icon in the wrong account. It install it in Public instead of the account I am currently using. I don't put any desktop icons in public. Can this please be fixed even if it's just a requester asking where to put the desktop icon? Assuming where to put it is not a good idea as not everyone does things the same way.

The application is installed for all users so the desktop icon is accessible for all users.

JSWolf · 08-06-2011, 04:15 PM

Quote:

Originally Posted by user_none

The application is installed for all users so the desktop icon is accessible for all users.

But not all users want the desktop icons in Public. I don't for one. So what's the harm in a requester asking where to put the icon? All that happens is I have to move the icon because it's in the wrong place and that puts it out of alphabetical order.

user_none · 08-06-2011, 04:54 PM

Quote:

Originally Posted by JSWolf

But not all users want the desktop icons in Public. I don't for one. So what's the harm in a requester asking where to put the icon? All that happens is I have to move the icon because it's in the wrong place and that puts it out of alphabetical order.

I'll look into it.

crutledge · 08-06-2011, 05:24 PM

The only way I can explicitly illistrate my questions is by showing exactly what I am addressing.

The HTML file loaded carrys SigilChapterBreaks in all the desired places.

before.jpg is the state of content.opf just after load, save, split, and toc generation. The first files in the Manifest are out of order (not a logical problem but an asthetic one) and the Spine is OK.

after1.jpg shows the state of contents.opf after renaming Section0001.xhtml to Cover.xhtml. The href has changed to Cover.xhtml but the id is unchanged. The Spine also remains unchanged.

after2.jpg shows the same situation after changing Section002.xhtm to TitlePage.xhtml.

I believe that good practice would have all references track in contents.opf. Any thing else can lead to confusion.

In no case does Flight Crew find any problems.

I will appreciate any comments.

charleski · 08-06-2011, 07:12 PM

Ok, to be honest, I have difficulty seeing this as a problem. It's more a matter of convenience.

We were worried there might have been some side-effect of the changes that were made to fix the issues with chapter splitting, but it seems this is not the case.

The spine retains the logical ordering of the files as specified in the Book Browser, and there's nothing that breaks the standard or produces an incorrect output.

The only place where ordering matters in the opf is in the spine. Outside that, this is essentially the same as the other issue about the ordering of a metadata attributes - it just doesn't matter, and any program that assumes things will occur in a certain order is broken. The ids used have no purpose other than to allow the spine to reference items in the manifest.

It could be fixed, but the cost would be to slow the program down unnecessarily and introduce more things that could go wrong. Remember that the opf file is only meant to be read by an XML parser - in fact one of the points of Sigil is that it removes the necessity to code or alter it yourself except in specialised circumstances. I'm having trouble thinking of anything you might want to edit in the manifest or spine that you couldn't do much more easily and safely in the Book Browser. Sigil uses filenames for the ids more as a matter of coding convenience than anything else. Again, this is code that's only meant to be read by an XML parser and making it easier to read doesn't confer any functional benefit.

So, it might get changed at a later date if the code is refactored, but I really wouldn't worry about it.

user_none · 08-06-2011, 07:46 PM

Quote:

Originally Posted by crutledge

The href has changed to Cover.xhtml but the id is unchanged. The Spine also remains unchanged.

This is just a cosmetic issue and while it would be nice to have the id change during a rename it isn't a high priority because:

Quote:

Originally Posted by crutledge

In no case does Flight Crew find any problems.

Feel free to open a bug so that it doesn't get forgotten about. It's still a nice idea to have just not something I feel is a high priority.

Quote:

Originally Posted by crutledge

Neither 64bit version will run on Win 7.

I'm working on a new x64 build right now. I'm hoping it finishes sometime tonight and works.

Quote:

Originally Posted by st_albert

I only wish I could have wrung out the Linux version, to see if there are any (remaining) KDE issues.

I'm thinking about dropping the Linux binary builds. x86 and x64 Linux version account for less than 10% of downloads. The next lowest download is Windows x64 and it had over 2x as many downloads as both Linux builds combined. Also, it's much easier to build Sigil on Linux vs any other platform.

st_albert · 08-06-2011, 08:10 PM

Quote:

Originally Posted by user_none

I'm thinking about dropping the Linux binary builds. x86 and x64 Linux version account for less than 10% of downloads. The next lowest download is Windows x64 and it had over 2x as many downloads as both Linux builds combined. Also, it's much easier to build Sigil on Linux vs any other platform.

OOOOH NOOOOOO! Guess I'll just have to learn how to build it myself then.

If you do put together that linux VM with the development environment that you mentioned on another thread, I hope it will be compatible with VirtualBox.

ETA:
Actually I just tried building 0.3.4 without success. Since it's off topic of this thread, I started another one here.

Rand Brittain · 08-06-2011, 10:26 PM

I use Sigil on several Linux machines and would be sad to lose binaries. So sad. Please don't make me cry in a public forum.

JSWolf · 08-06-2011, 10:32 PM

Quote:

Originally Posted by user_none

I'll look into it.

Thank you.

theducks · 08-06-2011, 11:22 PM

Quote:

Originally Posted by theducks

there does not seem to be any other way to make a TOC.ncx other than by hand (we lost the F7 (TOC_editor) and now the 'regenerate' button).

I also found that I needed to manually edit the Manifest

after renaming some sections (the manifest had the original name for the id)

Operator Error

(the keystroke for the TOC editor changed and I was being blind.

roger64 · 08-07-2011, 02:10 AM

Quote:

Originally Posted by user_none

I'm thinking about dropping the Linux binary builds. x86 and x64 Linux version account for less than 10% of downloads. The next lowest download is Windows x64 and it had over 2x as many downloads as both Linux builds combined. Also, it's much easier to build Sigil on Linux vs any other platform.

Please don't do it, specially as we may have to use V4 a loooooong time.

Linux downloads may have been quite low these last months because before the last v4rc, the Linux binary build of Sigil was huge and some Linux users may have kept away from the v03.4 version just because of that (at least that happened for me).

I tried to build a binary for the 0.34 version and failed. That's really not easy for average users. My last successful try was when I proposed a deb to Valloric two years ago but he refused it because it was not a universal Linux build and came from "random people".

https://www.mobileread.com/forums/sho...3&postcount=39

Hitch · 08-07-2011, 03:19 AM

Quote:

Originally Posted by user_none

I'm thinking about dropping the Linux binary builds. x86 and x64 Linux version account for less than 10% of downloads. The next lowest download is Windows x64 and it had over 2x as many downloads as both Linux builds combined. Also, it's much easier to build Sigil on Linux vs any other platform.

Oh, nonononononono.

Please don't. We use Linux builds for production. My guys haven't DL'ed it yet, because we're still using 0.3x for production, as we're, well, in production, and can't have the type of wonkiness that 0.4x has been having. But they will be.

Hitch

EowynCarter · 08-07-2011, 07:08 AM

Quote:

I'm thinking about dropping the Linux binary builds. x86 and x64 Linux version account for less than 10% of downloads. The next lowest download is Windows x64 and it had over 2x as many downloads as both Linux builds combined. Also, it's much easier to build Sigil on Linux vs any other platform.

Oh nooooo!

Goodbye sigil then.

user_none · 08-07-2011, 09:27 AM

If this many active users are using the Linux build than I will continue to support it. However, it will push the 0.4.0 release out by at least a week. I'm shooting for next weekend. Also, there probably won't be a Linux RC build.

08-06-2011, 05:24 PM	#20
crutledge eBook FANatic Posts: 18,301 Karma: 16078357 Join Date: Apr 2008 Location: Alabama, USA Device: HP ipac RX5915 Wife's Kindle	Questions with pictures. The only way I can explicitly illistrate my questions is by showing exactly what I am addressing. The HTML file loaded carrys SigilChapterBreaks in all the desired places. *before.jpg* is the state of content.opf just after load, save, split, and toc generation. The first files in the Manifest are out of order (not a logical problem but an asthetic one) and the Spine is OK. *after1.jpg* shows the state of contents.opf after renaming Section0001.xhtml to Cover.xhtml. The href has changed to Cover.xhtml but the id is unchanged. The Spine also remains unchanged. *after2.jpg* shows the same situation after changing Section002.xhtm to TitlePage.xhtml. I believe that good practice would have all references track in contents.opf. Any thing else can lead to confusion. In no case does Flight Crew find any problems. I will appreciate any comments. Attached Thumbnails

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
No Avaliable format ? ? ?	Janette55	Library Management	5	04-16-2011 04:09 PM
Idea for Consideration in Future Builds of Calibre	Fi3ryPh03n1x	Library Management	40	04-08-2011 05:12 PM
Daily builds, what happened?	cloggy	OpenInkpot	2	01-15-2011 11:55 AM
New daily builds are stable again?	cloggy	OpenInkpot	14	05-31-2010 08:47 AM
Current daily builds do not work on V3ext	AlfonsVH	OpenInkpot	7	04-22-2010 08:13 PM

08-06-2011, 01:09 PM	#16
JSWolf Resident Curmudgeon Posts: 79,741 Karma: 145864619 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I do have one issue with the installer. It installs the desktop icon in the wrong account. It install it in Public instead of the account I am currently using. I don't put any desktop icons in public. Can this please be fixed even if it's just a requester asking where to put the desktop icon? Assuming where to put it is not a good idea as not everyone does things the same way.

08-06-2011, 07:12 PM	#21
charleski Wizard Posts: 1,196 Karma: 1281258 Join Date: Sep 2009 Device: PRS-505	Ok, to be honest, I have difficulty seeing this as a problem. It's more a matter of convenience. We were worried there might have been some side-effect of the changes that were made to fix the issues with chapter splitting, but it seems this is not the case. The spine retains the logical ordering of the files as specified in the Book Browser, and there's nothing that breaks the standard or produces an incorrect output. The only place where ordering matters in the opf is in the spine. Outside that, this is essentially the same as the other issue about the ordering of a metadata attributes - it just doesn't matter, and any program that assumes things will occur in a certain order is broken. The ids used have no purpose other than to allow the spine to reference items in the manifest. It could be fixed, but the cost would be to slow the program down unnecessarily and introduce more things that could go wrong. Remember that the opf file is only meant to be read by an XML parser - in fact one of the points of Sigil is that it removes the necessity to code or alter it yourself except in specialised circumstances. I'm having trouble thinking of anything you might want to edit in the manifest or spine that you couldn't do much more easily and safely in the Book Browser. Sigil uses filenames for the ids more as a matter of coding convenience than anything else. Again, this is code that's only meant to be read by an XML parser and making it easier to read doesn't confer any functional benefit. So, it might get changed at a later date if the code is refactored, but I really wouldn't worry about it.

08-06-2011, 10:26 PM	#24
Rand Brittain Bookmaker Posts: 427 Karma: 2143650 Join Date: Sep 2010 Device: Cybook Opus	I use Sigil on several Linux machines and would be sad to lose binaries. So sad. Please don't make me cry in a public forum.

08-07-2011, 09:27 AM	#30
user_none Sigil & calibre developer Posts: 2,487 Karma: 1063785 Join Date: Jan 2009 Location: Florida, USA Device: Nook STR	If this many active users are using the Linux build than I will continue to support it. However, it will push the 0.4.0 release out by at least a week. I'm shooting for next weekend. Also, there probably won't be a Linux RC build.