Hello Everyone!
In this post I would be focusing on the work done in the past two weeks,
issues faced and how I went about resolving them. Also, since the first
evaluation is near, the post also contains a brief analysis of the current
progress with respect to the deliverables mentioned in the proposal.
Issues faced and how I went about resolving them:
- I wasn't able to set the day names header in the calendar view based on
the locale preferences, the day names always showed up in English no matter
which language is selected in locale preferences. The Calendar view uses
BDate::ShortDayName() which in turn uses strfime to get the day of week
names, and it uses LC_TIME to decide which locale to use. By default it is
set to use the "C" locale set which is a rather neutral locale with minimal
locale information. In order to use the locale set selected in the
environment, setlocale(LC_ALL,"") has to be called. But still work has to be
done to update it with live changes in locale preferences.
<li>This was not an issue but still I have to look into several
implementations in order to find a proper way do this i.e updating the date
headers with changes in system date. I'm making the MainView in the calendar
app accept pulse messages(using B_PULSE_NEEDED) and every time the Pulse()
method is called I'm checking the system date and sending the state change
message using SendNotices() to all the other subscribers(currently there is
only one- SidePanelView that contains the date header and calendar views)
and calling the method to update the date header in the SidePanelView class
on receiving the message. Instead of using pulse, BMessageRunner can also be
used to send periodic messages.</li>
<li>There was a bit difficulty in updating the date headers and calendar
view day name headers with live changes in locale preferences as I was
unsure about how the handle B_LOCALE_CHANGED message. When locale preference
are changed BApplication gets the B_LOCALE_CHANGED message, I am forwarding
the message to SidePanelView and updating the headers based on the new locale
preferences. Work has to be done in updating the day name headers in the
calendar view on locale preferences change.</li>
<li>I explored the Haiku message-passing system in details and had a few
doubts regarding how to post and forward messages as there are similar ways
of doing itand used interchangeably in the existing applications. Stippi and
PulkoMandy helped me in understanding it better.</li>
<li>In the calendar view when I change the selected day, the current day
doesn't remain highlighted. Also if a day which is not in the current month
is selected, then I cannot bring the focus back to the current day
programmatically i.e the CalendarView::SetDate() doesn't work. I am working
to fix this.</li>
<p><img src="/files/blog/AkshayAgarwal007/calendar-focus.png" alt="Calendar"
class="img-responsive center-block"></p>
<li> This is more of a learning than an issue. Haiku uses a 32-bit time_t
and therefore is vulnerable to the Y2038 problem</li> So if events are set
to happen after the date 19-January-2038 3:14:08 AM GMT, they would cause
problems. Moreover the system date cannot be set to a date after Y2038
currently. Waddlesplash has recently worked to switch to a 64-bit time_t
and that is applicable for x86_64 build and not for 32-bit x86 and the Y2038
will remain the same for it. We will hopefully drop 32-bit support by 2038.
So for 32-bit x86 the calendar would not support dates after Jaunary 19th
2038.</li>
I also implemented preferences settings for the app. The user can enable/disable
week number and set the first day of week(which can be set to locale based first
day of week or any specific day.)
Greetings
Almost 2 weeks since the last Weekly Report, so here goes what I have been up to in the last two weeks.
Adding code
I am slowly adding new code as you might see here. Each commit represents a new file and its dependencies compiling successfully in my machine(gcc5). In asm/atomic.h I have commented out some of the functions which I believe is not required for DRM. If I find some use of those functions then I will have to revisit this file and make the necessary changes. Also, I have used some compiler (gcc5) functions in asm/atomic which will later have to be changed appropriately for use with gcc2 if that is desired.
Hello everyone,
I spent last 2 weeks mainly for researching and forming an complete idea so that something will not be changed much in the future and some coding. These things are what I did in the previous 2 weeks:
I implemented a “cat” command in btrfs_shell for testing, since current fs_shell misses read file content command.
Refixed ticket #127883. This is the ticket I fixed as a proof to attend GSoC for Haiku, but it is hardcoded. I simply changed the block size to node size (the old block size is sector size), so that block_cache can cache the whole node instead of caching multiple blocks with old block size, and reverted back the old code. I misunderstood in the past that block is sector but that is not always (at least in BtrFS case). In BtrFS, metadata is in tree block (node) and file data is in extent (a continous run of sectors), so with block_cache API I can easily manipulate tree node and with file_cache API for read/write files. I had a hard time to figure out how to write with cache, but after reading BFS and block_cache codebase, it can be done easily with memcpy for copying data to cache and block_cache_sync for flushing to disk.
Hello World.
This is my first blog post after the Coding Period officially began, I’ve started to write code for the application. During the Community Bonding period, I got the menu listing for SuperPrefs. My last exam got over on June 6. I worked on the basic application layout during the beginning of June. This was how the application looked initially:
The application hosts seperate sections for holding the Preferences based on their category. I also added a Search field for searching the contents of an application, though this has not been implemented yet.
Hello everyone! This is a rather short update on the Swift port and since the last blog post, I’ve worked around a small issue that prevented the compiler from importing libraries by specifying the -sdk parameter with a ‘/’ which passes the correct header search paths to swiftc. This issue also existed on other platforms such as FreeBSD according to this thread in the swift-dev mailing list [1]. Whilst researching around the frequent swift interpreter crashes when opening a swift source file, the fault lies in libswiftCore being unable to extract type metadata from swift-generated dynamic libraries when calling these functions specified in the ProtocolConformance and Metadata classes. It is also evident that whenever swift attempts to load this metadata at runtime, it uses ‘dl_iterate_phdr()’ to iterate over every ELF object loaded into the process address-space and will initiate a callback that will emit internal ELF information defined in the dl_phdr_info* struct. I will spend this week with my mentors to implement a Haiku replacement for this function.
Hey there, it's time for the monthly report again!
This report covers hrev51139-hrev51195.
User interface
Brian Hill fixed a glitch in the Screen preferences. The preference panel
shows a preview o the screen, and as a nice finishing touch, it adopts the
current background color. However, this did not anticipate that the color
could change while the application is running. Now the screen preferences is
notified when such a change happens, so it can update itself completely to the
new color.
Hello again
Here goes my second weekly report describing my efforts and endeavours in the last two weeks. I haven’t produced a lot of code, but I am not sitting idle.
Technical Report
Firstly, as advised by Alex (kallisti5), I have a Technical Report[1] prepared - a rough outline of how and what all changes to the codebase are planned for this summer project. It is a very basic roadmap which I will try my best to stick to but cannot guarantee.
Hello Everyone!
In this post I would be focusing on my last two weeks of community bonding.
The coding period has officially began on 30th, although I had already started
it in my second week itself.
I had one or two different things in mind for this week as I mentioned in my
previous post. But I ended up working on implementing a locale aware date
header, and the calendar widget, which is more important initially as to
implement the basic functionalities of the calendar app, and is also the first
goal. In the process, I also gained a better understanding of the locale kit
and Haiku date/time classes.
Hello Everyone,
This is my third blog post and the last post on my work during communty bond period. The coding period has officially started! Yay!
I have started working on a application that renders text using FreeType and Harfbuzz you can find it here. It has two branches one of them successfully compiles and renders some some text in English using already existing technology in Haiku. The other branch "broken" will include all my latest updates, harfbuzz & freetype library and probably won't compile. You might even this that few things in the code can be implemented in a better way.
Hy there!
I am writing this blog as a combined report for the past 2 weeks. As I mentioned on the mailing this, I had college exams till 25th. Really hectic. But I have been able to get some work done from then.
Community bonding
Didn't get a chance to know a lot of them but I did break some conversation with a few people. My short talk with axeld on the IRC got me into knowing the names responsible for the current implementation of TCP in Haiku. Axel has also been helpful in pointing me towards some useful resoures. Also had a short talk with tojoko.
